Re: [Nouveau] [PATCH v2 06/22] volt: parse the both max voltage entries
On 28/03/16 23:49, Martin Peres wrote:
On 21/03/16 18:16, Karol Herbst wrote:
these entries specify a maximum voltage nvidia never exceeds, we shouldn't do
that, too.
Signed-off-by: Karol Herbst
---
drm/nouveau/include/nvkm/subdev/bios/vmap.h | 2 ++
drm/nouveau/include/nvkm/subdev/volt.h | 2 ++
drm/nouveau/nvkm/subdev/bios/vmap.c | 5 +
drm/nouveau/nvkm/subdev/volt/base.c | 11 +++
4 files changed, 20 insertions(+)
diff --git a/drm/nouveau/include/nvkm/subdev/bios/vmap.h
b/drm/nouveau/include/nvkm/subdev/bios/vmap.h
index 6633c6d..48fe71d 100644
--- a/drm/nouveau/include/nvkm/subdev/bios/vmap.h
+++ b/drm/nouveau/include/nvkm/subdev/bios/vmap.h
@@ -1,6 +1,8 @@
#ifndef __NVBIOS_VMAP_H__
#define __NVBIOS_VMAP_H__
struct nvbios_vmap {
+ u8 max0;
+ u8 max1;
};
u16 nvbios_vmap_table(struct nvkm_bios *, u8 *ver, u8 *hdr, u8 *cnt, u8 *len);
diff --git a/drm/nouveau/include/nvkm/subdev/volt.h
b/drm/nouveau/include/nvkm/subdev/volt.h
index fc68825..3e0f8da 100644
--- a/drm/nouveau/include/nvkm/subdev/volt.h
+++ b/drm/nouveau/include/nvkm/subdev/volt.h
@@ -15,6 +15,8 @@ struct nvkm_volt {
u32 max_uv;
u32 min_uv;
+ u8 max0_vid;
+ u8 max1_vid;
};
int nvkm_volt_map_min(struct nvkm_volt *volt, u8 id);
diff --git a/drm/nouveau/nvkm/subdev/bios/vmap.c
b/drm/nouveau/nvkm/subdev/bios/vmap.c
index 2f13db7..f5463b1 100644
--- a/drm/nouveau/nvkm/subdev/bios/vmap.c
+++ b/drm/nouveau/nvkm/subdev/bios/vmap.c
@@ -61,7 +61,12 @@ nvbios_vmap_parse(struct nvkm_bios *bios, u8 *ver, u8 *hdr,
u8 *cnt, u8 *len,
memset(info, 0x00, sizeof(*info));
switch (!!vmap * *ver) {
case 0x10:
+ info->max0 = 0xff;
+ info->max1 = 0xff;
+ break;
case 0x20:
+ info->max0 = nvbios_rd08(bios, vmap + 0x7);
+ info->max1 = nvbios_rd08(bios, vmap + 0x8);
break;
}
return vmap;
diff --git a/drm/nouveau/nvkm/subdev/volt/base.c
b/drm/nouveau/nvkm/subdev/volt/base.c
index 71094a9..205dfcf 100644
--- a/drm/nouveau/nvkm/subdev/volt/base.c
+++ b/drm/nouveau/nvkm/subdev/volt/base.c
@@ -217,9 +217,20 @@ nvkm_volt_ctor(const struct nvkm_volt_func *func, struct
nvkm_device *device,
/* Assuming the non-bios device should build the voltage table later */
if (bios) {
+ u8 ver, hdr, cnt, len;
+ struct nvbios_vmap vmap;
+
nvkm_volt_parse_bios(bios, volt);
nvkm_debug(&volt->subdev, "min: %iuv max: %iuv\n",
volt->min_uv, volt->max_uv);
+
+ if (nvbios_vmap_parse(bios, &ver, &hdr, &cnt, &len, &vmap)) {
+ volt->max0_vid = vmap.max0;
+ volt->max1_vid = vmap.max1;
+ } else {
+ volt->max0_vid = 0xff;
+ volt->max1_vid = 0xff;
+ }
}
if (volt->vid_nr) {
This is really peculiar that NVIDIA would have 2 max_vid in the same
entry :s
How did you reverse that? Did you really see no differences? Maybe the
two max_vid are for different temperatures?
Ok, after discussions on IRC, I understand better. Max0/1 is actually
not a vid but an entry in the voltage mapping table, which has different
coefficient for the temperature. This allows OEMs to clamp the maximum
voltage with not one but two different functions. I can see why it is OK.
Can you explain this a little more? Maybe as a comment in the code?
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2 22/22] debugfs: add boost interface to change the boost_mode
On 21/03/16 18:16, Karol Herbst wrote: Signed-off-by: Karol Herbst 21-22 are: Reviewed-by: Martin Peres ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2 07/22] volt: add min_id parameter to nvkm_volt_set_id
On 28/03/16 23:52, Martin Peres wrote: On 21/03/16 18:16, Karol Herbst wrote: min_id indicates a volt map entry which acts as a floor value, this will be used to set the lower voltage limit through pstates Please state that this comes that this min_id is different for each pstate, hence why volt should not know about this and needs to take it as an input! Signed-off-by: Karol Herbst Do we really want to push reclocking logic to the volt subsystem? To me, volt should just allow you to read back and set a voltage. All the rest of the logic should be in clk. Since this is my first NAK, here are my R-b for 3, 4 and 5: Reviewed-by: Martin Peres With this fixed, this patch is Reviewed-by: Martin Peres ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2 07/22] volt: add min_id parameter to nvkm_volt_set_id
On 21/03/16 18:16, Karol Herbst wrote: min_id indicates a volt map entry which acts as a floor value, this will be used to set the lower voltage limit through pstates Signed-off-by: Karol Herbst Do we really want to push reclocking logic to the volt subsystem? To me, volt should just allow you to read back and set a voltage. All the rest of the logic should be in clk. Since this is my first NAK, here are my R-b for 3, 4 and 5: Reviewed-by: Martin Peres ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2 06/22] volt: parse the both max voltage entries
On 21/03/16 18:16, Karol Herbst wrote:
these entries specify a maximum voltage nvidia never exceeds, we shouldn't do
that, too.
Signed-off-by: Karol Herbst
---
drm/nouveau/include/nvkm/subdev/bios/vmap.h | 2 ++
drm/nouveau/include/nvkm/subdev/volt.h | 2 ++
drm/nouveau/nvkm/subdev/bios/vmap.c | 5 +
drm/nouveau/nvkm/subdev/volt/base.c | 11 +++
4 files changed, 20 insertions(+)
diff --git a/drm/nouveau/include/nvkm/subdev/bios/vmap.h
b/drm/nouveau/include/nvkm/subdev/bios/vmap.h
index 6633c6d..48fe71d 100644
--- a/drm/nouveau/include/nvkm/subdev/bios/vmap.h
+++ b/drm/nouveau/include/nvkm/subdev/bios/vmap.h
@@ -1,6 +1,8 @@
#ifndef __NVBIOS_VMAP_H__
#define __NVBIOS_VMAP_H__
struct nvbios_vmap {
+ u8 max0;
+ u8 max1;
};
u16 nvbios_vmap_table(struct nvkm_bios *, u8 *ver, u8 *hdr, u8 *cnt, u8 *len);
diff --git a/drm/nouveau/include/nvkm/subdev/volt.h
b/drm/nouveau/include/nvkm/subdev/volt.h
index fc68825..3e0f8da 100644
--- a/drm/nouveau/include/nvkm/subdev/volt.h
+++ b/drm/nouveau/include/nvkm/subdev/volt.h
@@ -15,6 +15,8 @@ struct nvkm_volt {
u32 max_uv;
u32 min_uv;
+ u8 max0_vid;
+ u8 max1_vid;
};
int nvkm_volt_map_min(struct nvkm_volt *volt, u8 id);
diff --git a/drm/nouveau/nvkm/subdev/bios/vmap.c
b/drm/nouveau/nvkm/subdev/bios/vmap.c
index 2f13db7..f5463b1 100644
--- a/drm/nouveau/nvkm/subdev/bios/vmap.c
+++ b/drm/nouveau/nvkm/subdev/bios/vmap.c
@@ -61,7 +61,12 @@ nvbios_vmap_parse(struct nvkm_bios *bios, u8 *ver, u8 *hdr,
u8 *cnt, u8 *len,
memset(info, 0x00, sizeof(*info));
switch (!!vmap * *ver) {
case 0x10:
+ info->max0 = 0xff;
+ info->max1 = 0xff;
+ break;
case 0x20:
+ info->max0 = nvbios_rd08(bios, vmap + 0x7);
+ info->max1 = nvbios_rd08(bios, vmap + 0x8);
break;
}
return vmap;
diff --git a/drm/nouveau/nvkm/subdev/volt/base.c
b/drm/nouveau/nvkm/subdev/volt/base.c
index 71094a9..205dfcf 100644
--- a/drm/nouveau/nvkm/subdev/volt/base.c
+++ b/drm/nouveau/nvkm/subdev/volt/base.c
@@ -217,9 +217,20 @@ nvkm_volt_ctor(const struct nvkm_volt_func *func, struct
nvkm_device *device,
/* Assuming the non-bios device should build the voltage table later */
if (bios) {
+ u8 ver, hdr, cnt, len;
+ struct nvbios_vmap vmap;
+
nvkm_volt_parse_bios(bios, volt);
nvkm_debug(&volt->subdev, "min: %iuv max: %iuv\n",
volt->min_uv, volt->max_uv);
+
+ if (nvbios_vmap_parse(bios, &ver, &hdr, &cnt, &len, &vmap)) {
+ volt->max0_vid = vmap.max0;
+ volt->max1_vid = vmap.max1;
+ } else {
+ volt->max0_vid = 0xff;
+ volt->max1_vid = 0xff;
+ }
}
if (volt->vid_nr) {
This is really peculiar that NVIDIA would have 2 max_vid in the same
entry :s
How did you reverse that? Did you really see no differences? Maybe the
two max_vid are for different temperatures?
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4/4] iccsense: configure sensors like nvidia does
On 25/03/16 13:19, Karol Herbst wrote:
Signed-off-by: Karol Herbst
---
drm/nouveau/nvkm/subdev/iccsense/base.c | 68 +
1 file changed, 68 insertions(+)
diff --git a/drm/nouveau/nvkm/subdev/iccsense/base.c
b/drm/nouveau/nvkm/subdev/iccsense/base.c
index b6f6222..6f3709e 100644
--- a/drm/nouveau/nvkm/subdev/iccsense/base.c
+++ b/drm/nouveau/nvkm/subdev/iccsense/base.c
@@ -95,6 +95,63 @@ nvkm_iccsense_ina3221_read(struct nvkm_iccsense *iccsense,
40 * 8);
}
+static void
+nvkm_iccsense_ina2x9_config(struct nvkm_iccsense *iccsense,
+ struct nvkm_iccsense_sensor *sensor)
Maybe calling the sensor ina209 and using it also for 219 would be less
confusing, especially if a 229 is later released by TI.
+{
+ struct nvkm_subdev *subdev = &iccsense->subdev;
+ /* configuration:
+* 0x0007: 0x0007 shunt and bus continous
+* 0x0078: 0x0078 128 samples shunt
+* 0x0780: 0x0780 128 samples bus
+* 0x1800: 0x +-40 mV shunt range
+* 0x2000: 0x 16V FSR
+ */
+ u16 value = 0x07ff;
+ nvkm_debug(subdev, "config for sensor id %i: 0x%x\n", sensor->id,
value);
+ nv_wr16i2cr(sensor->i2c, sensor->addr, 0x00, value);
+}
+
+static void
+nvkm_iccsense_ina3221_config(struct nvkm_iccsense *iccsense,
+struct nvkm_iccsense_sensor *sensor)
+{
+ struct nvkm_subdev *subdev = &iccsense->subdev;
+ /* configuration:
+* 0x0007: 0x0007 shunt and bus continous
+* 0x0031: 0x 140 us conversion time shunt
+* 0x01c0: 0x 140 us conversion time bus
+* 0x0f00: 0x0f00 1024 samples
+* 0x7000: 0x?000 channels
+ */
+ u16 value = 0x0e07;
+ if (sensor->rail_mask & 0x1)
+ value |= 0x1 << 14;
+ if (sensor->rail_mask & 0x2)
+ value |= 0x1 << 13;
+ if (sensor->rail_mask & 0x4)
+ value |= 0x1 << 12;
+ nvkm_debug(subdev, "config for sensor id %i: 0x%x\n", sensor->id,
value);
+ nv_wr16i2cr(sensor->i2c, sensor->addr, 0x00, value);
+}
+
+static void
+nvkm_iccsense_sensor_config(struct nvkm_iccsense *iccsense,
+ struct nvkm_iccsense_sensor *sensor)
+{
+ switch (sensor->type) {
+ case NVBIOS_EXTDEV_INA209:
+ case NVBIOS_EXTDEV_INA219:
+ nvkm_iccsense_ina2x9_config(iccsense, sensor);
+ break;
+ case NVBIOS_EXTDEV_INA3221:
+ nvkm_iccsense_ina3221_config(iccsense, sensor);
+ break;
+ default:
+ break;
+ }
+}
+
int
nvkm_iccsense_read_all(struct nvkm_iccsense *iccsense)
{
@@ -257,8 +314,19 @@ nvkm_iccsense_oneinit(struct nvkm_subdev *subdev)
return 0;
}
+static int
+nvkm_iccsense_init(struct nvkm_subdev *subdev)
+{
+ struct nvkm_iccsense *iccsense = nvkm_iccsense(subdev);
+ struct nvkm_iccsense_sensor *sensor;
+ list_for_each_entry(sensor, &iccsense->sensors, head)
+ nvkm_iccsense_sensor_config(iccsense, sensor);
+ return 0;
+}
+
struct nvkm_subdev_func iccsense_func = {
.oneinit = nvkm_iccsense_oneinit,
+ .init = nvkm_iccsense_init,
.dtor = nvkm_iccsense_dtor,
};
Looks like a good cleanup and improvement to me!
With the free-ing the lists fixed and maybe the change in name for the
ina2x9, this is:
Martin Peres
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 3/4] iccsense: split sensor into own struct
On 25/03/16 13:19, Karol Herbst wrote:
Signed-off-by: Karol Herbst
---
drm/nouveau/include/nvkm/subdev/iccsense.h | 1 +
drm/nouveau/nvkm/subdev/iccsense/base.c| 141 -
drm/nouveau/nvkm/subdev/iccsense/priv.h| 15 ++-
3 files changed, 112 insertions(+), 45 deletions(-)
diff --git a/drm/nouveau/include/nvkm/subdev/iccsense.h
b/drm/nouveau/include/nvkm/subdev/iccsense.h
index a4c0da0..3c2ddd9 100644
--- a/drm/nouveau/include/nvkm/subdev/iccsense.h
+++ b/drm/nouveau/include/nvkm/subdev/iccsense.h
@@ -6,6 +6,7 @@
struct nvkm_iccsense {
struct nvkm_subdev subdev;
bool data_valid;
+ struct list_head sensors;
struct list_head rails;
};
diff --git a/drm/nouveau/nvkm/subdev/iccsense/base.c b/drm/nouveau/nvkm/subdev/iccsense/base.c
index 6fde68d..b6f6222 100644
--- a/drm/nouveau/nvkm/subdev/iccsense/base.c
+++ b/drm/nouveau/nvkm/subdev/iccsense/base.c
@@ -30,15 +30,14 @@
static bool
nvkm_iccsense_validate_device(struct i2c_adapter *i2c, u8 addr,
- enum nvbios_extdev_type type, u8 rail)
+ enum nvbios_extdev_type type)
{
switch (type) {
case NVBIOS_EXTDEV_INA209:
case NVBIOS_EXTDEV_INA219:
- return rail == 0 && nv_rd16i2cr(i2c, addr, 0x0) >= 0;
+ return nv_rd16i2cr(i2c, addr, 0x0) >= 0;
case NVBIOS_EXTDEV_INA3221:
- return rail <= 3 &&
- nv_rd16i2cr(i2c, addr, 0xff) == 0x3220 &&
+ return nv_rd16i2cr(i2c, addr, 0xff) == 0x3220 &&
nv_rd16i2cr(i2c, addr, 0xfe) == 0x5449;
default:
return false;
@@ -67,8 +66,9 @@ nvkm_iccsense_ina2x9_read(struct nvkm_iccsense *iccsense,
struct nvkm_iccsense_rail *rail,
u8 shunt_reg, u8 bus_reg)
{
- return nvkm_iccsense_poll_lane(rail->i2c, rail->addr, shunt_reg, 0,
- bus_reg, 3, rail->mohm, 10 * 4);
+ return nvkm_iccsense_poll_lane(rail->sensor->i2c, rail->sensor->addr,
+ shunt_reg, 0, bus_reg, 3, rail->mohm,
+ 10 * 4);
}
static int
@@ -89,9 +89,9 @@ static int
nvkm_iccsense_ina3221_read(struct nvkm_iccsense *iccsense,
struct nvkm_iccsense_rail *rail)
{
- return nvkm_iccsense_poll_lane(rail->i2c, rail->addr,
- 1 + (rail->rail * 2), 3,
- 2 + (rail->rail * 2), 3, rail->mohm,
+ return nvkm_iccsense_poll_lane(rail->sensor->i2c, rail->sensor->addr,
+ 1 + (rail->idx * 2), 3,
+ 2 + (rail->idx * 2), 3, rail->mohm,
40 * 8);
}
@@ -121,81 +121,137 @@ static void *
nvkm_iccsense_dtor(struct nvkm_subdev *subdev)
{
struct nvkm_iccsense *iccsense = nvkm_iccsense(subdev);
- struct nvkm_iccsense_rail *rail, *tmp;
+ struct nvkm_iccsense_sensor *sensor, *tmps;
+ struct nvkm_iccsense_rail *rail, *tmpr;
- list_for_each_entry_safe(rail, tmp, &iccsense->rails, head)
+ list_for_each_entry_safe(sensor, tmps, &iccsense->sensors, head)
+ kfree(sensor);
+ list_for_each_entry_safe(rail, tmpr, &iccsense->rails, head)
kfree(rail);
Same problem as the last patch.
return iccsense;
}
+static struct nvkm_iccsense_sensor*
+nvkm_iccsense_create_sensor(struct nvkm_iccsense *iccsense, u8 id)
+{
+
+ struct nvkm_subdev *subdev = &iccsense->subdev;
+ struct nvkm_bios *bios = subdev->device->bios;
+ struct nvkm_i2c *i2c = subdev->device->i2c;
+ struct nvbios_extdev_func extdev;
+ struct nvkm_i2c_bus *i2c_bus;
+ struct nvkm_iccsense_sensor *sensor;
+ u8 addr;
+
+ if (!i2c || !bios || nvbios_extdev_parse(bios, id, &extdev))
+ return NULL;
+
+ if (extdev.type == 0xff)
+ return NULL;
+
+ if (extdev.type != NVBIOS_EXTDEV_INA209 &&
+ extdev.type != NVBIOS_EXTDEV_INA219 &&
+ extdev.type != NVBIOS_EXTDEV_INA3221) {
+ iccsense->data_valid = false;
+ nvkm_error(subdev, "found unknown sensor type %x, "
+ "power reading might be invalid\n",
+ extdev.type);
You do not create the sensor if it is unknown, so why do you say the
report might be invalid?
Please change it to "Unknown sensor type %x".
+ return NULL;
+ }
+
+ if (extdev.bus)
+ i2c_bus = nvkm_i2c_bus_find(i2c, NVKM_I2C_BUS_SEC);
+ else
+ i2c_bus = nvkm_i2c_bus_find(i2c, NVKM_I2C_BUS_PRI);
+ if (!i2c_bus)
+ return NULL;
+
+ addr = extdev.addr >> 1;
+ if (!nvkm_iccsense_validate_device(&i2c_bus->i2c, a
Re: [Nouveau] [PATCH 2/4] iccsense: convert to linked list
On 25/03/16 13:19, Karol Herbst wrote:
Signed-off-by: Karol Herbst
---
drm/nouveau/include/nvkm/subdev/iccsense.h | 4 +---
drm/nouveau/nouveau_hwmon.c| 2 +-
drm/nouveau/nvkm/subdev/iccsense/base.c| 32 +-
drm/nouveau/nvkm/subdev/iccsense/priv.h| 1 +
4 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/drm/nouveau/include/nvkm/subdev/iccsense.h
b/drm/nouveau/include/nvkm/subdev/iccsense.h
index c3defcd..a4c0da0 100644
--- a/drm/nouveau/include/nvkm/subdev/iccsense.h
+++ b/drm/nouveau/include/nvkm/subdev/iccsense.h
@@ -3,12 +3,10 @@
#include
-struct nkvm_iccsense_rail;
struct nvkm_iccsense {
struct nvkm_subdev subdev;
- u8 rail_count;
bool data_valid;
- struct nvkm_iccsense_rail *rails;
+ struct list_head rails;
};
int gf100_iccsense_new(struct nvkm_device *, int index, struct nvkm_iccsense **);
diff --git a/drm/nouveau/nouveau_hwmon.c b/drm/nouveau/nouveau_hwmon.c
index 67edd2f..74f237b 100644
--- a/drm/nouveau/nouveau_hwmon.c
+++ b/drm/nouveau/nouveau_hwmon.c
@@ -689,7 +689,7 @@ nouveau_hwmon_init(struct drm_device *dev)
goto error;
}
- if (iccsense && iccsense->data_valid && iccsense->rail_count) {
+ if (iccsense && iccsense->data_valid && !list_empty(&iccsense->rails)) {
ret = sysfs_create_group(&hwmon_dev->kobj,
&hwmon_power_attrgroup);
if (ret)
diff --git a/drm/nouveau/nvkm/subdev/iccsense/base.c
b/drm/nouveau/nvkm/subdev/iccsense/base.c
index bf1b94e..6fde68d 100644
--- a/drm/nouveau/nvkm/subdev/iccsense/base.c
+++ b/drm/nouveau/nvkm/subdev/iccsense/base.c
@@ -98,25 +98,21 @@ nvkm_iccsense_ina3221_read(struct nvkm_iccsense *iccsense,
int
nvkm_iccsense_read_all(struct nvkm_iccsense *iccsense)
{
- int result = 0, i;
+ int result = 0;
+ struct nvkm_iccsense_rail *rail;
if (!iccsense)
return -EINVAL;
- if (iccsense->rail_count == 0)
- return -ENODEV;
-
- for (i = 0; i < iccsense->rail_count; ++i) {
+ list_for_each_entry(rail, &iccsense->rails, head) {
int res;
- struct nvkm_iccsense_rail *rail = &iccsense->rails[i];
if (!rail->read)
return -ENODEV;
res = rail->read(iccsense, rail);
- if (res >= 0)
- result += res;
- else
+ if (res < 0)
return res;
+ result += res;
}
return result;
}
@@ -125,9 +121,10 @@ static void *
nvkm_iccsense_dtor(struct nvkm_subdev *subdev)
{
struct nvkm_iccsense *iccsense = nvkm_iccsense(subdev);
+ struct nvkm_iccsense_rail *rail, *tmp;
- if (iccsense->rails)
- kfree(iccsense->rails);
+ list_for_each_entry_safe(rail, tmp, &iccsense->rails, head)
+ kfree(rail);
The rails list is filled with invalid pointers at this point. Please add
list_del(rail); before kfree(rail);
It has the added benefit of adding poisonous pointers that will show any
access after freeing.
return iccsense;
}
@@ -145,11 +142,6 @@ nvkm_iccsense_oneinit(struct nvkm_subdev *subdev)
|| !stbl.nr_entry)
return 0;
- iccsense->rails = kmalloc(sizeof(*iccsense->rails) * stbl.nr_entry,
- GFP_KERNEL);
- if (!iccsense->rails)
- return -ENOMEM;
-
iccsense->data_valid = true;
for (i = 0; i < stbl.nr_entry; ++i) {
struct pwr_rail_t *r = &stbl.rail[i];
@@ -184,7 +176,10 @@ nvkm_iccsense_oneinit(struct nvkm_subdev *subdev)
continue;
}
- rail = &iccsense->rails[iccsense->rail_count];
+ rail = kmalloc(sizeof(*rail), GFP_KERNEL);
+ if (!rail)
+ return -ENOMEM;
+
switch (extdev.type) {
case NVBIOS_EXTDEV_INA209:
rail->read = nvkm_iccsense_ina209_read;
@@ -201,7 +196,7 @@ nvkm_iccsense_oneinit(struct nvkm_subdev *subdev)
rail->rail = r->rail;
rail->mohm = r->resistor_mohm;
rail->i2c = &i2c_bus->i2c;
- ++iccsense->rail_count;
+ list_add_tail(&rail->head, &iccsense->rails);
}
return 0;
}
@@ -224,6 +219,7 @@ nvkm_iccsense_new_(struct nvkm_device *device, int index,
{
if (!(*iccsense = kzalloc(sizeof(**iccsense), GFP_KERNEL)))
return -ENOMEM;
+ INIT_LIST_HEAD(&(*iccsense)->rails);
nvkm_iccsense_ctor(device, index, *iccsense);
return 0;
}
diff --git a/drm/nouveau/nvkm/subdev/iccsense/priv.h
b/drm/nouveau/nvkm/subdev/iccsense/priv.h
index ed398b8..e479128 100644
--- a/drm/nouveau/nvkm/subdev/iccsense/priv.h
+++ b/drm/nouveau/nvkm/subdev/iccsense/priv.h
Re: [Nouveau] [PATCH 05/19] clk: allow boosting only when NvBoost is set
, 0x06 },
diff --git a/drm/nouveau/nvkm/subdev/clk/gk104.c
b/drm/nouveau/nvkm/subdev/clk/gk104.c
index 975c401..639234f 100644
--- a/drm/nouveau/nvkm/subdev/clk/gk104.c
+++ b/drm/nouveau/nvkm/subdev/clk/gk104.c
@@ -485,7 +485,7 @@ gk104_clk = {
.domains = {
{ nv_clk_src_crystal, 0xff },
{ nv_clk_src_href , 0xff },
- { nv_clk_src_gpc, 0x00, NVKM_CLK_DOM_FLAG_CORE, "core",
2000 },
+ { nv_clk_src_gpc, 0x00, NVKM_CLK_DOM_FLAG_CORE |
NVKM_CLK_DOM_FLAG_BASECLK, "core", 2000 },
{ nv_clk_src_hubk07 , 0x01, NVKM_CLK_DOM_FLAG_CORE },
{ nv_clk_src_rop, 0x02, NVKM_CLK_DOM_FLAG_CORE },
{ nv_clk_src_mem, 0x03, 0, "memory", 500 },
Reviewed-by: Martin Peres
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 04/19] clk: print the base clocks
On 18/03/16 01:03, Karol Herbst wrote:
Signed-off-by: Karol Herbst
---
drm/nouveau/nvkm/subdev/clk/base.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drm/nouveau/nvkm/subdev/clk/base.c
b/drm/nouveau/nvkm/subdev/clk/base.c
index 889cce2..4928668 100644
--- a/drm/nouveau/nvkm/subdev/clk/base.c
+++ b/drm/nouveau/nvkm/subdev/clk/base.c
@@ -24,6 +24,7 @@
#include "priv.h"
#include
+#include
#include
#include
#include
@@ -561,10 +562,24 @@ int
nvkm_clk_ctor(const struct nvkm_clk_func *func, struct nvkm_device *device,
int index, bool allow_reclock, struct nvkm_clk *clk)
{
+ struct nvkm_subdev *subdev = &clk->subdev;
+ struct nvkm_bios *bios = device->bios;
int ret, idx, arglen;
const char *mode;
+ struct nvbios_baseclk_header h;
+
+ nvkm_subdev_ctor(&nvkm_clk, device, index, 0, subdev);
+
+ if (bios && !nvbios_baseclock_parse(bios, &h)) {
+ struct nvbios_baseclk_entry base, boost;
+ if (!nvbios_baseclock_entry(bios, &h, h.boost, &boost))
+ nvkm_info(subdev, "boost: %i MHz\n",
+ boost.clock_mhz / 2);
+ if (!nvbios_baseclock_entry(bios, &h, h.base, &base))
+ nvkm_info(subdev, "base: %i MHz\n",
+ base.clock_mhz / 2);
+ }
- nvkm_subdev_ctor(&nvkm_clk, device, index, 0, &clk->subdev);
clk->func = func;
INIT_LIST_HEAD(&clk->states);
clk->domains = func->domains;
I would rather have you report this information in debugfs, if you don't
mind.
This is really out of place, especially since we do not show the clocks
anymore apparently.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 03/19] bios: add parsing of BASE CLOCK table
On 18/03/16 01:03, Karol Herbst wrote:
this table contains three important clocks:
base clock: this is the non boosted max clock
tdp clock: the clock at wich the vbios guarentees the TDP won't ever be
exceeded at max load (seems to be always the same as the base
clock, but behaves differently)
boost clock: the avg clock the gpu will stay boosted to. It doesn't seem to
affect the behaviour of the nvidia driver at all though.
Signed-off-by: Karol Herbst
---
drm/nouveau/include/nvkm/subdev/bios/baseclock.h | 24 +++
drm/nouveau/nvkm/subdev/bios/Kbuild | 1 +
drm/nouveau/nvkm/subdev/bios/baseclock.c | 82
3 files changed, 107 insertions(+)
create mode 100644 drm/nouveau/include/nvkm/subdev/bios/baseclock.h
create mode 100644 drm/nouveau/nvkm/subdev/bios/baseclock.c
diff --git a/drm/nouveau/include/nvkm/subdev/bios/baseclock.h
b/drm/nouveau/include/nvkm/subdev/bios/baseclock.h
new file mode 100644
index 000..eca7b4a
--- /dev/null
+++ b/drm/nouveau/include/nvkm/subdev/bios/baseclock.h
@@ -0,0 +1,24 @@
+#ifndef __NVBIOS_BASECLOCK_H__
+#define __NVBIOS_BASECLOCK_H__
+struct nvbios_baseclk_header {
+ u16 offset;
+
+ u8 version;
+ u8 hlen;
+ u8 ecount;
+ u8 elen;
+ u8 scount;
+ u8 slen;
+
+ u8 base;
+ u8 boost;
+ u8 tdp;
Maybe it would be easier to understand if you said that base, boost and
tdp are actual entry ids.
Other than this, looks good! Congrats for figuring this table out!
Reviewed-by: Martin Peres
+};
+struct nvbios_baseclk_entry {
+ u8 pstate;
+ u16 clock_mhz;
+};
+int nvbios_baseclock_parse(struct nvkm_bios *, struct nvbios_baseclk_header *);
+int nvbios_baseclock_entry(struct nvkm_bios *, struct nvbios_baseclk_header *,
+ u8 idx, struct nvbios_baseclk_entry *);
+#endif
diff --git a/drm/nouveau/nvkm/subdev/bios/Kbuild
b/drm/nouveau/nvkm/subdev/bios/Kbuild
index dbcb0ef..6cb3beb 100644
--- a/drm/nouveau/nvkm/subdev/bios/Kbuild
+++ b/drm/nouveau/nvkm/subdev/bios/Kbuild
@@ -1,4 +1,5 @@
nvkm-y += nvkm/subdev/bios/base.o
+nvkm-y += nvkm/subdev/bios/baseclock.o
nvkm-y += nvkm/subdev/bios/bit.o
nvkm-y += nvkm/subdev/bios/boost.o
nvkm-y += nvkm/subdev/bios/conn.o
diff --git a/drm/nouveau/nvkm/subdev/bios/baseclock.c
b/drm/nouveau/nvkm/subdev/bios/baseclock.c
new file mode 100644
index 000..2f15abb
--- /dev/null
+++ b/drm/nouveau/nvkm/subdev/bios/baseclock.c
@@ -0,0 +1,82 @@
+/*
+ * Copyright 2016 Karol Herbst
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Karol Herbst
+ */
+#include
+#include
+#include
+
+static u16
+nvbios_baseclock_offset(struct nvkm_bios *b)
+{
+ struct bit_entry bit_P;
+
+ if (!bit_entry(b, 'P', &bit_P)) {
+ if (bit_P.version == 2)
+ return nvbios_rd16(b, bit_P.offset + 0x38);
+ }
+
+ return 0x;
+}
+
+int
+nvbios_baseclock_parse(struct nvkm_bios *b, struct nvbios_baseclk_header *h)
+{
+ if (!h)
+ return -EINVAL;
+
+ h->offset = nvbios_baseclock_offset(b);
+ if (!h->offset)
+ return -ENODEV;
+
+ h->version = nvbios_rd08(b, h->offset);
+ switch (h->version) {
+ case 0x10:
+ h->hlen = nvbios_rd08(b, h->offset + 0x1);
+ h->elen = nvbios_rd08(b, h->offset + 0x2);
+ h->slen = nvbios_rd08(b, h->offset + 0x3);
+ h->scount = nvbios_rd08(b, h->offset + 0x4);
+ h->ecount = nvbios_rd08(b, h->offset + 0x5);
+
+ h->base = nvbios_rd08(b, h->offset + 0x0f);
+ h->boost = nvbios_rd08(b, h->offset + 0x10);
+ h->tdp= nvbios_rd08(b, h->offset + 0x11);
+ re
Re: [Nouveau] [PATCH v2 2/2] volt: properly detect entry based voltage tables
veau/nvkm/subdev/volt/base.c
+++ b/drm/nouveau/nvkm/subdev/volt/base.c
@@ -112,6 +112,7 @@ nvkm_volt_set_id(struct nvkm_volt *volt, u8 id, int
condition)
static void
nvkm_volt_parse_bios(struct nvkm_bios *bios, struct nvkm_volt *volt)
{
+ struct nvkm_subdev *subdev = &bios->subdev;
struct nvbios_volt_entry ivid;
struct nvbios_volt info;
u8 ver, hdr, cnt, len;
@@ -119,7 +120,8 @@ nvkm_volt_parse_bios(struct nvkm_bios *bios, struct
nvkm_volt *volt)
int i;
data = nvbios_volt_parse(bios, &ver, &hdr, &cnt, &len, &info);
- if (data && info.vidmask && info.base && info.step) {
+ if (data && info.vidmask && info.base && info.step &&
!info.entry_based) {
+ nvkm_debug(subdev, "found header based VIDs\n");
for (i = 0; i < info.vidmask + 1; i++) {
if (info.base >= info.min &&
info.base <= info.max) {
@@ -130,7 +132,8 @@ nvkm_volt_parse_bios(struct nvkm_bios *bios, struct
nvkm_volt *volt)
info.base += info.step;
}
volt->vid_mask = info.vidmask;
- } else if (data && info.vidmask) {
+ } else if (data && info.vidmask && info.entry_based) {
+ nvkm_debug(subdev, "found entry based VIDs\n");
for (i = 0; i < cnt; i++) {
data = nvbios_volt_entry_parse(bios, i, &ver, &hdr,
&ivid);
Both patches are:
Reviewed-by: Martin Peres
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 3/4] pmu/fuc: call# seems to be broken on gk208
On 01/03/16 23:53, Ilia Mirkin wrote: On Tue, Mar 1, 2016 at 4:45 PM, Martin Peres wrote: On 26/02/16 17:19, Karol Herbst wrote: for some reasons these calls don't really go there where they should go leading to various corruptions of the PMU state I am fine with the changes but not fine at all with the commit message. it would be nice if you could understand a bit more what the problem is instead of just saying: "it works with this change (TM)" The problem is that the call macro exists for a reason, but it was (accidentally) not being used here. Agreed, I checked before sending this email. Hence why I was fine with the change but not the change log. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4/4] pmu/fuc: movw is somewhat weird on gk208, use mov instead
On 01/03/16 23:38, Ilia Mirkin wrote: On Tue, Mar 1, 2016 at 4:36 PM, Martin Peres wrote: On 26/02/16 17:19, Karol Herbst wrote: currently there is no change, because nobody uses those macros yet, but they shouldn't stay broken Signed-off-by: Karol Herbst --- drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc b/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc index 0d5cbeb..bb59eb4 100644 --- a/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc +++ b/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc @@ -252,12 +252,12 @@ #endif #define st(size, addr, reg) /* -*/ movw $r0 addr /* +*/ mov $r0 addr /* First of all, I know it is annoying, but we *need* to understand exactly what movw is now doing. Secondly, I seem to remember that a 32 bit mov was not added until fuc3 or fuc5 Ah, right, fuc3 was on the GT2xx. Thanks! something. Have you tried assembling this code on older fuc versions? Pretty sure it will fail. That's what the imm32() macro is for. Right, with the mov replace with the imm32 macro, this patch will have my R-b! ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 3/4] pmu/fuc: call# seems to be broken on gk208
On 26/02/16 17:19, Karol Herbst wrote: for some reasons these calls don't really go there where they should go leading to various corruptions of the PMU state I am fine with the changes but not fine at all with the commit message. it would be nice if you could understand a bit more what the problem is instead of just saying: "it works with this change (TM)" Anyway, 1-3 are: Reviewed-by: Martin Peres ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/4] pmu/fuc: replace mov+sethi with imm32
On 26/02/16 17:19, Karol Herbst wrote: on gk208+ we can simply mov 32bits, so we should have a single mov there Signed-off-by: Karol Herbst diff --git a/drm/nouveau/nvkm/subdev/pmu/fuc/host.fuc b/drm/nouveau/nvkm/subdev/pmu/fuc/host.fuc index c2bb616..f2420a3 100644 --- a/drm/nouveau/nvkm/subdev/pmu/fuc/host.fuc +++ b/drm/nouveau/nvkm/subdev/pmu/fuc/host.fuc @@ -98,8 +98,7 @@ host_send: // $r0 - zero host_recv: // message from intr handler == HOST->PWR comms pending - mov $r1 (PROC_KERN & 0x) - sethi $r1 (PROC_KERN & 0x) + imm32($r1, PROC_KERN) cmp b32 $r14 $r1 bra e #host_send diff --git a/drm/nouveau/nvkm/subdev/pmu/fuc/kernel.fuc b/drm/nouveau/nvkm/subdev/pmu/fuc/kernel.fuc index ad35fa5..d1ca3c7 100644 --- a/drm/nouveau/nvkm/subdev/pmu/fuc/kernel.fuc +++ b/drm/nouveau/nvkm/subdev/pmu/fuc/kernel.fuc @@ -51,8 +51,7 @@ time_next: .b32 0 // $r0 - zero rd32: nv_iowr(NV_PPWR_MMIO_ADDR, $r14) - mov $r13 NV_PPWR_MMIO_CTRL_OP_RD - sethi $r13 NV_PPWR_MMIO_CTRL_TRIGGER + imm32($r13, NV_PPWR_MMIO_CTRL_OP_RD + NV_PPWR_MMIO_CTRL_TRIGGER) nv_iowr(NV_PPWR_MMIO_CTRL, $r13) rd32_wait: nv_iord($r13, NV_PPWR_MMIO_CTRL) @@ -70,9 +69,7 @@ rd32: wr32: nv_iowr(NV_PPWR_MMIO_ADDR, $r14) nv_iowr(NV_PPWR_MMIO_DATA, $r13) - mov $r13 NV_PPWR_MMIO_CTRL_OP_WR - or $r13 NV_PPWR_MMIO_CTRL_MASK_B32_0 - sethi $r13 NV_PPWR_MMIO_CTRL_TRIGGER + imm32($r13, (NV_PPWR_MMIO_CTRL_OP_WR | NV_PPWR_MMIO_CTRL_MASK_B32_0) + NV_PPWR_MMIO_CTRL_TRIGGER) #ifdef NVKM_FALCON_MMIO_TRAP push $r13 @@ -215,8 +212,7 @@ intr: bra z #intr_subintr_skip_fifo nv_iord($r12, NV_PPWR_FIFO_INTR) push $r12 - mov $r14 (PROC_HOST & 0x) - sethi $r14 (PROC_HOST & 0x) + imm32($r14, PROC_HOST) mov $r13 KMSG_FIFO call(send) pop $r12 @@ -511,14 +507,12 @@ init: #ifdef NVKM_FALCON_MMIO_UAS // somehow allows the magic "access mmio via D[]" stuff that's // used by the nv_rd32/nv_wr32 macros to work - mov $r1 0x0010 - sethi $r1 NV_PPWR_UAS_CONFIG_ENABLE + imm32($r1, 0x10 + NV_PPWR_UAS_CONFIG_ENABLE) nv_iowrs(NV_PPWR_UAS_CONFIG, $r1) #endif // route all interrupts except user0/1 and pause to fuc - mov $r1 0x00e0 - sethi $r1 0x + imm32($r1, 0xe0) nv_iowr(NV_PPWR_INTR_ROUTE, $r1) // enable watchdog and subintr intrs @@ -529,8 +523,8 @@ init: nv_iowr(NV_PPWR_INTR_EN_SET, $r1) // enable interrupts globally - mov $r1 #intr - sethi $r1 0x + imm32($r1, #intr) + and $r1 0x mov $iv0 $r1 bset $flags ie0 diff --git a/drm/nouveau/nvkm/subdev/pmu/fuc/test.fuc b/drm/nouveau/nvkm/subdev/pmu/fuc/test.fuc index 0c3a71b..9e3f4e6 100644 --- a/drm/nouveau/nvkm/subdev/pmu/fuc/test.fuc +++ b/drm/nouveau/nvkm/subdev/pmu/fuc/test.fuc @@ -48,8 +48,7 @@ test_recv: nv_iord($r1, NV_PPWR_DSCRATCH(2)) add b32 $r1 1 nv_iowr(NV_PPWR_DSCRATCH(2), $r1) - mov $r14 -0x2700 /* 0xd900, envyas grrr! */ - sethi $r14 0x134f + imm32($r14, 0x134fd900) call(timer) ret Improves readability and performance (not that we care), looks good! ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/4] pmu/fuc: fix imm32 for gk208+
On 26/02/16 17:19, Karol Herbst wrote: Signed-off-by: Karol Herbst diff --git a/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc b/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc index 96fc984..0d5cbeb 100644 --- a/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc +++ b/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc @@ -169,7 +169,7 @@ */.b32 0 /* */.skip 64 -#if NV_PPWR_CHIPSET < GK208 +#if NVKM_PPWR_CHIPSET < GK208 Oopsie! Good catch! ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4/4] pmu/fuc: movw is somewhat weird on gk208, use mov instead
On 26/02/16 17:19, Karol Herbst wrote: currently there is no change, because nobody uses those macros yet, but they shouldn't stay broken Signed-off-by: Karol Herbst --- drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc b/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc index 0d5cbeb..bb59eb4 100644 --- a/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc +++ b/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc @@ -252,12 +252,12 @@ #endif #define st(size, addr, reg) /* -*/ movw $r0 addr /* +*/ mov $r0 addr /* First of all, I know it is annoying, but we *need* to understand exactly what movw is now doing. Secondly, I seem to remember that a 32 bit mov was not added until fuc3 or something. Have you tried assembling this code on older fuc versions? Pretty sure it will fail. */st size D[$r0] reg /* */clear b32 $r0 #define ld(size, reg, addr) /* -*/ movw $r0 addr /* +*/ mov $r0 addr /* */ld size reg D[$r0] /* */clear b32 $r0 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 1/6] subdev/iccsense: add new subdev for power sensors
On 20/02/16 19:11, Karol Herbst wrote: From: Martin Peres Signed-off-by: Karol Herbst Reviewed-by: Martin Peres ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 3/6] iccsense: implement for ina209, ina219 and ina3221
On 20/02/16 19:11, Karol Herbst wrote:
based on Martins initial work
v3: fix ina2x9 calculations
v4: don't kmalloc(0), fix the lsb/pga stuff
Signed-off-by: Karol Herbst
---
drm/nouveau/include/nvkm/subdev/bios/extdev.h | 3 +
drm/nouveau/include/nvkm/subdev/i2c.h | 31 ++
drm/nouveau/include/nvkm/subdev/iccsense.h| 5 +
drm/nouveau/nvkm/engine/device/base.c | 20
drm/nouveau/nvkm/subdev/iccsense/Kbuild | 1 +
drm/nouveau/nvkm/subdev/iccsense/base.c | 150 +-
drm/nouveau/nvkm/subdev/iccsense/gf100.c | 31 ++
drm/nouveau/nvkm/subdev/iccsense/priv.h | 8 ++
8 files changed, 248 insertions(+), 1 deletion(-)
create mode 100644 drm/nouveau/nvkm/subdev/iccsense/gf100.c
diff --git a/drm/nouveau/nvkm/subdev/iccsense/base.c
b/drm/nouveau/nvkm/subdev/iccsense/base.c
index 5dfa2fd..29c6641 100644
--- a/drm/nouveau/nvkm/subdev/iccsense/base.c
+++ b/drm/nouveau/nvkm/subdev/iccsense/base.c
@@ -23,13 +23,161 @@
*/
#include "priv.h"
-struct nvkm_subdev_func iccsense_func = { 0 };
+#include
+#include
+#include
+#include
+
+static int
+nvkm_iccsense_poll_lane(struct i2c_adapter *i2c, u8 addr, u8 shunt_reg,
+ u8 shunt_shift, u8 bus_reg, u8 bus_shift, u8 shunt,
+ u16 lsb)
+{
+ int vbus, vshunt;
+
+ if (shunt == 0)
+ return 0;
+
+ vshunt = nv_rd16i2cr(i2c, addr, shunt_reg);
+ vbus = nv_rd16i2cr(i2c, addr, bus_reg);
+
+ if (vshunt < 0 || vbus < 0)
+ return -EINVAL;
+
+ vshunt >>= shunt_shift;
+ vbus >>= bus_shift;
+
+ return (vbus * vshunt * lsb) / shunt;
+}
+
+static int
+nvkm_iccsense_ina2x9_read(struct nvkm_iccsense *iccsense,
+ struct nvkm_iccsense_rail *rail,
+ u8 shunt_reg, u8 bus_reg)
+{
+ return nvkm_iccsense_poll_lane(rail->i2c, rail->addr, shunt_reg, 0,
+ bus_reg, 3, rail->mohm, 10 * 4);
+}
+
+static int
+nvkm_iccsense_ina209_read(struct nvkm_iccsense *iccsense,
+ struct nvkm_iccsense_rail *rail)
+{
+ return nvkm_iccsense_ina2x9_read(iccsense, rail, 3, 4);
+}
+
+static int
+nvkm_iccsense_ina219_read(struct nvkm_iccsense *iccsense,
+ struct nvkm_iccsense_rail *rail)
+{
+ return nvkm_iccsense_ina2x9_read(iccsense, rail, 1, 2);
+}
+
+static int
+nvkm_iccsense_ina3221_read(struct nvkm_iccsense *iccsense,
+ struct nvkm_iccsense_rail *rail)
+{
+ if (rail->rail >= 3)
+ return -EINVAL;
+
+ return nvkm_iccsense_poll_lane(rail->i2c, rail->addr,
+ 1 + (rail->rail * 2), 3,
+ 2 + (rail->rail * 2), 3, rail->mohm,
+ 40 * 8);
+}
+
+int
+nkvm_iccsense_read(struct nvkm_iccsense *iccsense, u8 idx)
+{
+ struct nvkm_iccsense_rail *rail;
+
+ if (!iccsense || idx >= iccsense->rail_count)
+ return -EINVAL;
+
+ rail = &iccsense->rails[idx];
+ if (!rail->read)
+ return -ENODEV;
+
+ return rail->read(iccsense, rail);
+}
+
+static void *
+nvkm_iccsense_dtor(struct nvkm_subdev *subdev)
+{
+ struct nvkm_iccsense *iccsense = nvkm_iccsense(subdev);
+
+ if (iccsense->rails)
+ kfree(iccsense->rails);
+
+ return iccsense;
+}
+
+struct nvkm_subdev_func iccsense_func = {
+ .dtor = nvkm_iccsense_dtor,
+};
int
nvkm_iccsense_ctor(struct nvkm_device *device, int index,
struct nvkm_iccsense *iccsense)
{
+ struct nvkm_bios *bios;
+ struct nvkm_i2c *i2c;
+ struct nvbios_iccsense stbl;
+ int i;
+
nvkm_subdev_ctor(&iccsense_func, device, index, 0, &iccsense->subdev);
+ bios = device->bios;
+ i2c = device->i2c;
+
+ if (!i2c || !bios || nvbios_iccsense_parse(bios, &stbl)
+ || !stbl.nr_entry)
I must say that this line is a bit ugly ... but meh!
+ return 0;
+
+ iccsense->rails = kmalloc(sizeof(*iccsense->rails) * stbl.nr_entry,
+ GFP_KERNEL);
+ if (!iccsense->rails)
+ return -ENOMEM;
+
+ for (i = 0; i < stbl.nr_entry; ++i) {
+ struct pwr_rail_t *r = &stbl.rail[i];
+ struct nvbios_extdev_func extdev;
+ struct nvkm_iccsense_rail *rail;
+ struct nvkm_i2c_bus *i2c_bus;
+
+ if (!r->mode)
+ continue;
+
+ if (nvbios_extdev_parse(bios, r->extdev_id, &extdev))
+ continue;
+
+ if (extdev.bus)
+ i2c_bus = nvkm_i2c_bus_find(i2c, NVKM_I2C_BUS_SEC);
+ else
+ i2c_bus = nvkm_i2c_bus_find(i2c, NVKM_I2C_BUS_PRI);
+ if (!i2c_bus)
+ continue;
Wow,
Re: [Nouveau] [PATCH v4 4/6] hwmon: add power consumption
On 20/02/16 19:11, Karol Herbst wrote:
Signed-off-by: Karol Herbst
---
drm/nouveau/include/nvif/device.h | 1 +
drm/nouveau/nouveau_hwmon.c | 39 +++
2 files changed, 40 insertions(+)
diff --git a/drm/nouveau/include/nvif/device.h
b/drm/nouveau/include/nvif/device.h
index e0ed2f4..bcb9817 100644
--- a/drm/nouveau/include/nvif/device.h
+++ b/drm/nouveau/include/nvif/device.h
@@ -62,6 +62,7 @@ u64 nvif_device_time(struct nvif_device *);
#define nvxx_gpio(a) nvxx_device(a)->gpio
#define nvxx_clk(a) nvxx_device(a)->clk
#define nvxx_i2c(a) nvxx_device(a)->i2c
+#define nvxx_iccsense(a) nvxx_device(a)->iccsense
#define nvxx_therm(a) nvxx_device(a)->therm
#define nvxx_volt(a) nvxx_device(a)->volt
diff --git a/drm/nouveau/nouveau_hwmon.c b/drm/nouveau/nouveau_hwmon.c
index 8e13467..c4f77f5 100644
--- a/drm/nouveau/nouveau_hwmon.c
+++ b/drm/nouveau/nouveau_hwmon.c
@@ -34,6 +34,7 @@
#include "nouveau_drm.h"
#include "nouveau_hwmon.h"
+#include
#include
#if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE))
@@ -543,6 +544,27 @@ nouveau_hwmon_get_in0_label(struct device *d,
static SENSOR_DEVICE_ATTR(in0_label, S_IRUGO,
nouveau_hwmon_get_in0_label, NULL, 0);
+static ssize_t
+nouveau_hwmon_get_power1_input(struct device *d, struct device_attribute *a,
+ char *buf)
+{
+ struct drm_device *dev = dev_get_drvdata(d);
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ struct nvkm_iccsense *iccsense = nvxx_iccsense(&drm->device);
+ int result = 0, i;
+
+ for (i = 0; i < iccsense->rail_count; ++i) {
+ int res = nkvm_iccsense_read(iccsense, i);
+ if (res > 0)
+ result += res;
+ }
The code above should be moved to the icc_sense I would say, as we will
likely need
to read the power from other places.
With such function added to the previous patch,
Reviewed-by: Martin Peres
+
+ return sprintf(buf, "%i\n", result);
+}
+
+static SENSOR_DEVICE_ATTR(power1_input, S_IRUGO,
+ nouveau_hwmon_get_power1_input, NULL, 0);
+
static struct attribute *hwmon_default_attributes[] = {
&sensor_dev_attr_name.dev_attr.attr,
&sensor_dev_attr_update_rate.dev_attr.attr,
@@ -579,6 +601,11 @@ static struct attribute *hwmon_in0_attributes[] = {
NULL
};
+static struct attribute *hwmon_power_attributes[] = {
+ &sensor_dev_attr_power1_input.dev_attr.attr,
+ NULL
+};
+
static const struct attribute_group hwmon_default_attrgroup = {
.attrs = hwmon_default_attributes,
};
@@ -594,6 +621,9 @@ static const struct attribute_group hwmon_pwm_fan_attrgroup
= {
static const struct attribute_group hwmon_in0_attrgroup = {
.attrs = hwmon_in0_attributes,
};
+static const struct attribute_group hwmon_power_attrgroup = {
+ .attrs = hwmon_power_attributes,
+};
#endif
int
@@ -603,6 +633,7 @@ nouveau_hwmon_init(struct drm_device *dev)
struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->device);
struct nvkm_volt *volt = nvxx_volt(&drm->device);
+ struct nvkm_iccsense *iccsense = nvxx_iccsense(&drm->device);
struct nouveau_hwmon *hwmon;
struct device *hwmon_dev;
int ret = 0;
@@ -662,6 +693,13 @@ nouveau_hwmon_init(struct drm_device *dev)
goto error;
}
+ if (iccsense && iccsense->rail_count) {
+ ret = sysfs_create_group(&hwmon_dev->kobj,
+&hwmon_power_attrgroup);
+ if (ret)
+ goto error;
+ }
+
hwmon->hwmon = hwmon_dev;
return 0;
@@ -688,6 +726,7 @@ nouveau_hwmon_fini(struct drm_device *dev)
sysfs_remove_group(&hwmon->hwmon->kobj,
&hwmon_pwm_fan_attrgroup);
sysfs_remove_group(&hwmon->hwmon->kobj,
&hwmon_fan_rpm_attrgroup);
sysfs_remove_group(&hwmon->hwmon->kobj, &hwmon_in0_attrgroup);
+ sysfs_remove_group(&hwmon->hwmon->kobj, &hwmon_power_attrgroup);
hwmon_device_unregister(hwmon->hwmon);
}
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 2/6] nvbios/iccsense: add parsing of the SENSE table
On 20/02/16 19:11, Karol Herbst wrote: From: Martin Peres v4: don't kmalloc(0) Signed-off-by: Karol Herbst Reviewed-by: Martin Peres ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 5/6] hwmon: don't require therm to be valid to get any data
On 20/02/16 19:11, Karol Herbst wrote:
Signed-off-by: Karol Herbst
Should never be an issue, but I get your point.
Reviewed-by: Martin Peres
---
drm/nouveau/nouveau_hwmon.c | 39 +++
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/drm/nouveau/nouveau_hwmon.c b/drm/nouveau/nouveau_hwmon.c
index c4f77f5..a630192 100644
--- a/drm/nouveau/nouveau_hwmon.c
+++ b/drm/nouveau/nouveau_hwmon.c
@@ -643,9 +643,6 @@ nouveau_hwmon_init(struct drm_device *dev)
return -ENOMEM;
hwmon->dev = dev;
- if (!therm || !therm->attr_get || !therm->attr_set)
- return -ENODEV;
-
hwmon_dev = hwmon_device_register(&dev->pdev->dev);
if (IS_ERR(hwmon_dev)) {
ret = PTR_ERR(hwmon_dev);
@@ -659,26 +656,28 @@ nouveau_hwmon_init(struct drm_device *dev)
if (ret)
goto error;
- /* if the card has a working thermal sensor */
- if (nvkm_therm_temp_get(therm) >= 0) {
- ret = sysfs_create_group(&hwmon_dev->kobj,
&hwmon_temp_attrgroup);
- if (ret)
- goto error;
- }
-
- /* if the card has a pwm fan */
- /*XXX: incorrect, need better detection for this, some boards have
-* the gpio entries for pwm fan control even when there's no
-* actual fan connected to it... therm table? */
- if (therm->fan_get && therm->fan_get(therm) >= 0) {
- ret = sysfs_create_group(&hwmon_dev->kobj,
-&hwmon_pwm_fan_attrgroup);
- if (ret)
- goto error;
+ if (therm && therm->attr_get && therm->attr_set) {
+ /* if the card has a working thermal sensor */
+ if (nvkm_therm_temp_get(therm) >= 0) {
+ ret = sysfs_create_group(&hwmon_dev->kobj,
&hwmon_temp_attrgroup);
+ if (ret)
+ goto error;
+ }
+
+ /* if the card has a pwm fan */
+ /*XXX: incorrect, need better detection for this, some boards
have
+* the gpio entries for pwm fan control even when there's no
+* actual fan connected to it... therm table? */
+ if (therm->fan_get && therm->fan_get(therm) >= 0) {
+ ret = sysfs_create_group(&hwmon_dev->kobj,
+&hwmon_pwm_fan_attrgroup);
+ if (ret)
+ goto error;
+ }
}
/* if the card can read the fan rpm */
- if (nvkm_therm_fan_sense(therm) >= 0) {
+ if (therm && nvkm_therm_fan_sense(therm) >= 0) {
ret = sysfs_create_group(&hwmon_dev->kobj,
&hwmon_fan_rpm_attrgroup);
if (ret)
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 6/6] bios/extdev: also parse v4.1 table
On 20/02/16 19:11, Karol Herbst wrote: Signed-off-by: Karol Herbst Right, this is needed for my GM206. I have not looked into the differences but the data made sense if parsed like v4.0. Reviewed-by: Martin Peres ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4/4] nouveau/debugfs: add interface for current load
On 26/10/15 20:17, Ilia Mirkin wrote:
On Mon, Oct 26, 2015 at 2:13 PM, Karol Herbst wrote:
From: Karol Herbst
---
drm/nouveau/include/nvif/device.h | 1 +
drm/nouveau/include/nvkm/subdev/pmu.h | 10 ++
drm/nouveau/nouveau_debugfs.c | 23 +++
drm/nouveau/nvkm/subdev/pmu/base.c| 18 ++
4 files changed, 52 insertions(+)
diff --git a/drm/nouveau/include/nvif/device.h
b/drm/nouveau/include/nvif/device.h
index 700a9b2..d289fdf 100644
--- a/drm/nouveau/include/nvif/device.h
+++ b/drm/nouveau/include/nvif/device.h
@@ -63,6 +63,7 @@ u64 nvif_device_time(struct nvif_device *);
#define nvxx_clk(a) nvxx_device(a)->clk
#define nvxx_i2c(a) nvxx_device(a)->i2c
#define nvxx_therm(a) nvxx_device(a)->therm
+#define nvxx_pmu(a) nvxx_device(a)->pmu
#include
#include
diff --git a/drm/nouveau/include/nvkm/subdev/pmu.h
b/drm/nouveau/include/nvkm/subdev/pmu.h
index e61923d..be3c60e 100644
--- a/drm/nouveau/include/nvkm/subdev/pmu.h
+++ b/drm/nouveau/include/nvkm/subdev/pmu.h
@@ -23,6 +23,13 @@ struct nvkm_pmu {
} recv;
};
+struct nvkm_pmu_load_data {
+ u8 core;
+ u8 mem;
+ u8 video;
+ u8 pcie;
+};
+
int nvkm_pmu_send(struct nvkm_pmu *, u32 reply[2], u32 process,
u32 message, u32 data0, u32 data1);
void nvkm_pmu_pgob(struct nvkm_pmu *, bool enable);
@@ -48,4 +55,7 @@ void nvkm_memx_train(struct nvkm_memx *);
int nvkm_memx_train_result(struct nvkm_pmu *, u32 *, int);
void nvkm_memx_block(struct nvkm_memx *);
void nvkm_memx_unblock(struct nvkm_memx *);
+
+/* interface to PERF process running on PMU */
+int nvkm_pmu_get_perf_data(struct nvkm_pmu *, struct nvkm_pmu_load_data *);
#endif
diff --git a/drm/nouveau/nouveau_debugfs.c b/drm/nouveau/nouveau_debugfs.c
index 5392e07..ec3d3d3 100644
--- a/drm/nouveau/nouveau_debugfs.c
+++ b/drm/nouveau/nouveau_debugfs.c
@@ -28,6 +28,8 @@
* Ben Skeggs
*/
+#include
+
#include "nouveau_debugfs.h"
#include "nouveau_drm.h"
@@ -43,8 +45,29 @@ nouveau_debugfs_vbios_image(struct seq_file *m, void *data)
return 0;
}
+static int
+nouveau_debugfs_current_load(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct nouveau_drm *drm = nouveau_drm(node->minor->dev);
+ struct nvkm_pmu *pmu = nvxx_pmu(&drm->device);
+ struct nvkm_pmu_load_data load_data;
+ int ret;
+
+ ret = nvkm_pmu_get_perf_data(pmu, &load_data);
+ if (ret < 0)
+ return ret;
+
+ seq_printf(m, "core: %i\n", load_data.core);
+ seq_printf(m, "mem: %i\n", load_data.mem);
+ seq_printf(m, "video: %i\n", load_data.video);
+ seq_printf(m, "pcie: %i\n", load_data.pcie);
+ return 0;
+}
+
static struct drm_info_list nouveau_debugfs_list[] = {
{ "vbios.rom", nouveau_debugfs_vbios_image, 0, NULL },
+ { "current_load", nouveau_debugfs_current_load, 0, NULL },
};
#define NOUVEAU_DEBUGFS_ENTRIES ARRAY_SIZE(nouveau_debugfs_list)
diff --git a/drm/nouveau/nvkm/subdev/pmu/base.c
b/drm/nouveau/nvkm/subdev/pmu/base.c
index d95eb86..ddb36e7 100644
--- a/drm/nouveau/nvkm/subdev/pmu/base.c
+++ b/drm/nouveau/nvkm/subdev/pmu/base.c
@@ -140,6 +140,24 @@ nvkm_pmu_recv(struct work_struct *work)
process, message, data0, data1);
}
+#define get_counter_index(v, i) (((v) & 0xff << ((i)*8)) >> ((i)*8))
Is this the same thing as
(v >> (i*8)) & 0xff
? I can't tell if you're attempting to preserve the sign, but don't
see why you'd want to since it all just becomes a u8 anyways.
There is no sign and the values are u8 anyway. So you are right, this is
what Karol should do.
+
+int
+nvkm_pmu_get_perf_data(struct nvkm_pmu *pmu, struct nvkm_pmu_load_data *data)
+{
+ int result[2], ret;
Given the bit manipulations, sounds like result should be (a) unsigned
and (b) sized.
Agreed. u32 is what he needs.
+ ret = nvkm_pmu_send(pmu, result, PROC_PERF, PERF_MSG_LOAD, 0, 0);
+
+ if (ret < 0)
+ return ret;
+
+ data->core = get_counter_index(result[0], 0);
+ data->video = get_counter_index(result[0], 1);
+ data->mem = get_counter_index(result[0], 2);
+ data->pcie = get_counter_index(result[0], 3);
+ return 0;
+}
+
static void
nvkm_pmu_intr(struct nvkm_subdev *subdev)
{
--
2.6.2
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 3/4] subdev/pmu/fuc: implement perf
On 26/10/15 20:13, Karol Herbst wrote: From: Karol Herbst --- drm/nouveau/nvkm/subdev/pmu/fuc/gf100.fuc3.h | 788 +++ drm/nouveau/nvkm/subdev/pmu/fuc/gf119.fuc4.h | 740 ++--- drm/nouveau/nvkm/subdev/pmu/fuc/gk104.fuc4.h | 740 ++--- drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h | 710 ++-- drm/nouveau/nvkm/subdev/pmu/fuc/gt215.fuc3.h | 755 ++--- drm/nouveau/nvkm/subdev/pmu/fuc/os.h | 4 + drm/nouveau/nvkm/subdev/pmu/fuc/perf.fuc | 148 + 7 files changed, 2267 insertions(+), 1618 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/pmu/fuc/os.h b/drm/nouveau/nvkm/subdev/pmu/fuc/os.h index c8b06cb..53508d9 100644 --- a/drm/nouveau/nvkm/subdev/pmu/fuc/os.h +++ b/drm/nouveau/nvkm/subdev/pmu/fuc/os.h @@ -49,4 +49,8 @@ #define I2C__MSG_DATA0_WR08_REG 0:7 #define I2C__MSG_DATA1_WR08_VAL 0:7 + +/* PERF: message identifiers */ +#define PERF_MSG_LOAD 1 Could you document the expected inputs and outputs of this message as a comment? // IN: don't care // OUT: // - byte 3: PCIe load (GF100+) // - byte 2: Memory load // - byte 1: Video decoding engines' load // - byte 0: GR load + #endif diff --git a/drm/nouveau/nvkm/subdev/pmu/fuc/perf.fuc b/drm/nouveau/nvkm/subdev/pmu/fuc/perf.fuc index 38eadf7..69a8f8d 100644 --- a/drm/nouveau/nvkm/subdev/pmu/fuc/perf.fuc +++ b/drm/nouveau/nvkm/subdev/pmu/fuc/perf.fuc @@ -30,6 +30,18 @@ process(PROC_PERF, #perf_init, #perf_recv) * PERF data segment */ #ifdef INCLUDE_DATA +perf_attr_start: +// parameters +perf_polling_period_us: .b32 10 + +// engine usage percentage It is a tiny bit misleading to say percentage when you mean per-255. How about: // engine usage (0-255) +perf_eng_gr: .b8 0 +perf_eng_vdec: .b8 0 +perf_eng_mc: .b8 0 +#if NVKM_PPWR_CHIPSET >= GF100 +perf_eng_pcie: .b8 0 +#endif +.align 4 #endif /** @@ -46,6 +58,78 @@ process(PROC_PERF, #perf_init, #perf_recv) // $r11 - data1 // $r0 - zero perf_recv: + push $r1 + + imm32($r10, PROC_HOST) + cmp b32 $r14 $r10 + bra ne #perf_recv_not_host + cmp b32 $r13 PERF_MSG_LOAD Thanks for doing this and not assuming straight away that this is going to be the only type of messages you will receive from the host :) + bra e #perf_load + bra #perf_recv_exit + +perf_load: + clear b32 $r11 + clear b32 $r12 +#if NVKM_PPWR_CHIPSET >= GF100 + ld(b8, $r12, #perf_eng_pcie) + shl b32 $r12 8 +#endif + ld(b8, $r12, #perf_eng_mc) + shl b32 $r12 8 + ld(b8, $r12, #perf_eng_vdec) + shl b32 $r12 8 + ld(b8, $r12, #perf_eng_gr) Simple and effective, that's nice :) + call(send) + bra #perf_recv_exit + +perf_recv_not_host: + call(perf_counter_readout) + + ld(b32, $r14, #perf_polling_period_us) + call #ticks_from_us + call(timer) + +perf_recv_exit: + pop $r1 + ret + + +// description +// +// $r15 - current (perf) +// $r0 - zero +perf_counter_readout: + nv_iord($r14, NV_PPWR_COUNTER_COUNT(0)) + div $r14 $r14 0xff Not a big fan of the loss in precision. Why do you do that instead of what I did here: https://cgit.freedesktop.org/~mperes/nouveau/tree/nvkm/subdev/pwr/fuc/perf.fuc?h=ppwr_rework&id=27310fa8fdc39e54a3f4383fada96a3562c5a022#n134 With my solution, you get no loss in precision. And you also poll the counters faster so it means a greater accuracy. I also miss less cycles. All in all, could you please reuse my polling function please? :D + + nv_iord($r13, NV_PPWR_COUNTER_COUNT(1)) + div $r13 $r13 $r14 + st(b8, #perf_eng_gr, $r13) + + nv_iord($r13, NV_PPWR_COUNTER_COUNT(2)) + div $r13 $r13 $r14 + st(b8, #perf_eng_vdec, $r13) + + nv_iord($r13, NV_PPWR_COUNTER_COUNT(3)) + div $r13 $r13 $r14 + st(b8, #perf_eng_mc, $r13) + +#if NVKM_PPWR_CHIPSET >= GF100 + nv_iord($r13, NV_PPWR_COUNTER_COUNT(4)) + div $r13 $r13 $r14 + st(b8, #perf_eng_pcie, $r13) +#endif + + // reset the counters + imm32($r14, NV_PPWR_COUNTER_COUNT_RESET) + nv_iowr(NV_PPWR_COUNTER_COUNT(0), $r14) + nv_iowr(NV_PPWR_COUNTER_COUNT(1), $r14) + nv_iowr(NV_PPWR_COUNTER_COUNT(2), $r14) + nv_iowr(NV_PPWR_COUNTER_COUNT(3), $r14) +#if NVKM_PPWR_CHIPSET >= GF100 + nv_iowr(NV_PPWR_COUNTER_COUNT(4), $r14) +#endif + ret // description @@ -53,5 +137,69 @@ perf_recv: // $r15 - current (perf) // $r0 - zero perf_init: + // set up the total ticks counter first +
Re: [Nouveau] [PATCH 2/4] pmu/fuc: add macros for pdaemon pwr counters
On 26/10/15 20:13, Karol Herbst wrote: From: Karol Herbst --- drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc b/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc index c5ec61f..86b8fd4 100644 --- a/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc +++ b/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc @@ -66,6 +66,29 @@ #define NV_PPWR_RFIFO_GET 0x04cc #define NV_PPWR_H2D 0x04d0 #define NV_PPWR_D2H 0x04dc +#define NV_PPWR_COUNTER_MASK(i)(0x10 * (i) + 0x0504) +#define NV_PPWR_COUNTER_COUNT(i) (0x10 * (i) + 0x0508) +#define NV_PPWR_COUNTER_COUNT_RESET 0x8000 +#define NV_PPWR_COUNTER_MODE(i)(0x10 * (i) + 0x050c) +#define NV_PPWR_COUNTER_MODE_NEVER0 +#define NV_PPWR_COUNTER_MODE_IF_ALL 1 +#define NV_PPWR_COUNTER_MODE_IF_NOT_ALL 2 +#define NV_PPWR_COUNTER_MODE_ALWAYS 3 +#define NV_PPWR_COUNTER_SIG_GR_IDLE 0x0001 +#define NV_PPWR_COUNTER_SIG_GR_HUB_IDLE 0x0002 +#define NV_PPWR_COUNTER_SIG_GR_GPC_IDLE 0x0004 +#define NV_PPWR_COUNTER_SIG_GR_ROP_IDLE 0x0008 +#define NV_PPWR_COUNTER_SIG_PVLD_IDLE0x0010 +#define NV_PPWR_COUNTER_SIG_PPDEC_IDLE 0x0020 +#define NV_PPWR_COUNTER_SIG__IDLE0x0040 +#define NV_PPWR_COUNTER_SIG_BFB_PART0_REQ0x0080 +#define NV_PPWR_COUNTER_SIG_FB_PART0_REQ 0x0100 +#define NV_PPWR_COUNTER_SIG_PMFB 0x1000 +#define NV_PPWR_COUNTER_SIG_PVENC0x0002 +#define NV_PPWR_COUNTER_SIG_PCOPY0_IDLE 0x0008 +#define NV_PPWR_COUNTER_SIG_PCOPY1_IDLE 0x0010 +#define NV_PPWR_COUNTER_SIG_PCOPY2_IDLE 0x0020 +#define NV_PPWR_COUNTER_SIG_PCIE 0x2000 #if NVKM_PPWR_CHIPSET < GK208 #define NV_PPWR_DSCRATCH(i) (4 * (i) + 0x05d0) #endif Why call the signals _IDLE when they are set when the engine is busy and cleared when idle? This is why I named the bitfield gt215_pdaemon_counter_busy_signals in envytools. With this fixed: Reviewed-by: Martin Peres ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/4] subdev/pmu/fuc: add gk104
On 26/10/15 20:13, Karol Herbst wrote: From: Karol Herbst we need this, because since kepler there is PCOPY2 and this is needed for the counters later in this series --- drm/nouveau/nvkm/subdev/pmu/fuc/gk104.fuc4 | 70 + drm/nouveau/nvkm/subdev/pmu/fuc/gk104.fuc4.h | 1795 ++ drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc |1 + drm/nouveau/nvkm/subdev/pmu/gk104.c |4 +- drm/nouveau/nvkm/subdev/pmu/gk110.c |6 +- 5 files changed, 1870 insertions(+), 6 deletions(-) create mode 100644 drm/nouveau/nvkm/subdev/pmu/fuc/gk104.fuc4 create mode 100644 drm/nouveau/nvkm/subdev/pmu/fuc/gk104.fuc4.h Reviewed-by: Martin Peres ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau contributor dinner Friday evening before FOSDEM?
On 21/01/16 15:09, Hans de Goede wrote: Hi All, $subject says it pretty much all. AFAIk quite a few nouveau contributors are coming to Fosdem, and I think it would be nice to have dinner together Friday evening before FOSDEM. So any takers? I'm in! ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] bios/fan: hardcode the fan mode to linear
On 05/01/16 10:38, Ben Skeggs wrote: On 01/05/2016 06:35 PM, Martin Peres wrote: On 04/01/16 18:42, Emil Velikov wrote: On 4 January 2016 at 14:56, Martin Peres wrote: On 17/12/15 19:18, Martin Peres wrote: On 29/11/15 16:10, Martin Peres wrote: This is an oversight that made use of the trip-point-based fan managenent on cards that never expose those. This led the fan to stay at fan_min. Fortunately, the emergency code would kick when the temperature would reach 90°C. Reported-by: Tom Englund Tested-by: Tom Englund Tested-by: Daemon32 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92126 Signed-off-by: Martin Peres --- drm/nouveau/nvkm/subdev/bios/fan.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drm/nouveau/nvkm/subdev/bios/fan.c b/drm/nouveau/nvkm/subdev/bios/fan.c index 43006db..80fed7e 100644 --- a/drm/nouveau/nvkm/subdev/bios/fan.c +++ b/drm/nouveau/nvkm/subdev/bios/fan.c @@ -83,6 +83,7 @@ nvbios_fan_parse(struct nvkm_bios *bios, struct nvbios_therm_fan *fan) fan->type = NVBIOS_THERM_FAN_UNK; } +fan->fan_mode = NVBIOS_THERM_FAN_LINEAR; fan->min_duty = nvbios_rd08(bios, data + 0x02); fan->max_duty = nvbios_rd08(bios, data + 0x03); Ben, can you merge this patch? It is kind of critical :s And it should be CCed to stable too, without it, some kepler/maxwell get 0% fan power which is kind of dangerous, even without reclocking! Ping, this is really important :s Not sure who picked it up, but it seems to be in the latest fixes batch [1]. [1] http://lists.freedesktop.org/archives/dri-devel/2015-December/097589.html Thanks Emil, Karol pointed it out to me on IRC too. Thanks to whoever picked it up :) I did, my apologies for not communicating that better! No probs :) Didn't know you moved to github too, it may be worth sending an email on the ML and we need to update the wiki. Are you planning on using the merge request feature to keep track of the review you need to make? We can also ask Damien Lespiau to set up a Nouveau instance of patchwork: https://patchwork.freedesktop.org/ ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] bios/fan: hardcode the fan mode to linear
On 04/01/16 18:42, Emil Velikov wrote: On 4 January 2016 at 14:56, Martin Peres wrote: On 17/12/15 19:18, Martin Peres wrote: On 29/11/15 16:10, Martin Peres wrote: This is an oversight that made use of the trip-point-based fan managenent on cards that never expose those. This led the fan to stay at fan_min. Fortunately, the emergency code would kick when the temperature would reach 90°C. Reported-by: Tom Englund Tested-by: Tom Englund Tested-by: Daemon32 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92126 Signed-off-by: Martin Peres --- drm/nouveau/nvkm/subdev/bios/fan.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drm/nouveau/nvkm/subdev/bios/fan.c b/drm/nouveau/nvkm/subdev/bios/fan.c index 43006db..80fed7e 100644 --- a/drm/nouveau/nvkm/subdev/bios/fan.c +++ b/drm/nouveau/nvkm/subdev/bios/fan.c @@ -83,6 +83,7 @@ nvbios_fan_parse(struct nvkm_bios *bios, struct nvbios_therm_fan *fan) fan->type = NVBIOS_THERM_FAN_UNK; } +fan->fan_mode = NVBIOS_THERM_FAN_LINEAR; fan->min_duty = nvbios_rd08(bios, data + 0x02); fan->max_duty = nvbios_rd08(bios, data + 0x03); Ben, can you merge this patch? It is kind of critical :s And it should be CCed to stable too, without it, some kepler/maxwell get 0% fan power which is kind of dangerous, even without reclocking! Ping, this is really important :s Not sure who picked it up, but it seems to be in the latest fixes batch [1]. [1] http://lists.freedesktop.org/archives/dri-devel/2015-December/097589.html Thanks Emil, Karol pointed it out to me on IRC too. Thanks to whoever picked it up :) ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] bios/fan: hardcode the fan mode to linear
On 17/12/15 19:18, Martin Peres wrote: On 29/11/15 16:10, Martin Peres wrote: This is an oversight that made use of the trip-point-based fan managenent on cards that never expose those. This led the fan to stay at fan_min. Fortunately, the emergency code would kick when the temperature would reach 90°C. Reported-by: Tom Englund Tested-by: Tom Englund Tested-by: Daemon32 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92126 Signed-off-by: Martin Peres --- drm/nouveau/nvkm/subdev/bios/fan.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drm/nouveau/nvkm/subdev/bios/fan.c b/drm/nouveau/nvkm/subdev/bios/fan.c index 43006db..80fed7e 100644 --- a/drm/nouveau/nvkm/subdev/bios/fan.c +++ b/drm/nouveau/nvkm/subdev/bios/fan.c @@ -83,6 +83,7 @@ nvbios_fan_parse(struct nvkm_bios *bios, struct nvbios_therm_fan *fan) fan->type = NVBIOS_THERM_FAN_UNK; } +fan->fan_mode = NVBIOS_THERM_FAN_LINEAR; fan->min_duty = nvbios_rd08(bios, data + 0x02); fan->max_duty = nvbios_rd08(bios, data + 0x03); Ben, can you merge this patch? It is kind of critical :s And it should be CCed to stable too, without it, some kepler/maxwell get 0% fan power which is kind of dangerous, even without reclocking! Ping, this is really important :s ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] bios/fan: hardcode the fan mode to linear
On 29/11/15 16:10, Martin Peres wrote: This is an oversight that made use of the trip-point-based fan managenent on cards that never expose those. This led the fan to stay at fan_min. Fortunately, the emergency code would kick when the temperature would reach 90°C. Reported-by: Tom Englund Tested-by: Tom Englund Tested-by: Daemon32 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92126 Signed-off-by: Martin Peres --- drm/nouveau/nvkm/subdev/bios/fan.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drm/nouveau/nvkm/subdev/bios/fan.c b/drm/nouveau/nvkm/subdev/bios/fan.c index 43006db..80fed7e 100644 --- a/drm/nouveau/nvkm/subdev/bios/fan.c +++ b/drm/nouveau/nvkm/subdev/bios/fan.c @@ -83,6 +83,7 @@ nvbios_fan_parse(struct nvkm_bios *bios, struct nvbios_therm_fan *fan) fan->type = NVBIOS_THERM_FAN_UNK; } + fan->fan_mode = NVBIOS_THERM_FAN_LINEAR; fan->min_duty = nvbios_rd08(bios, data + 0x02); fan->max_duty = nvbios_rd08(bios, data + 0x03); Ben, can you merge this patch? It is kind of critical :s And it should be CCed to stable too, without it, some kepler/maxwell get 0% fan power which is kind of dangerous, even without reclocking! ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] bios/fan: hardcode the fan mode to linear
This is an oversight that made use of the trip-point-based fan managenent on cards that never expose those. This led the fan to stay at fan_min. Fortunately, the emergency code would kick when the temperature would reach 90°C. Reported-by: Tom Englund Tested-by: Tom Englund Signed-off-by: Martin Peres --- drm/nouveau/nvkm/subdev/bios/fan.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drm/nouveau/nvkm/subdev/bios/fan.c b/drm/nouveau/nvkm/subdev/bios/fan.c index 43006db..80fed7e 100644 --- a/drm/nouveau/nvkm/subdev/bios/fan.c +++ b/drm/nouveau/nvkm/subdev/bios/fan.c @@ -83,6 +83,7 @@ nvbios_fan_parse(struct nvkm_bios *bios, struct nvbios_therm_fan *fan) fan->type = NVBIOS_THERM_FAN_UNK; } + fan->fan_mode = NVBIOS_THERM_FAN_LINEAR; fan->min_duty = nvbios_rd08(bios, data + 0x02); fan->max_duty = nvbios_rd08(bios, data + 0x03); -- 2.6.2 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Nouveau for FreeBSD
On 05/11/15 11:42, Francois Tigeot wrote: Martin Peres wrote: On 04/11/15 11:58, Pierre Moreau wrote: Wasn't there some work being done by François Tigeot or Jean-Sébastien Pédron to port Nouveau to DragonFlyBSD/FreeBSD? Or at least they were talking about porting it at XDC 2014, no idea what the current status is. From what they said, they never really cared about nvidia because nvidia provides a binary driver that works, unlike intel and amd. Hey, I never said that ! There has never been a Nvidia binary driver for DragonFly. Nvidia support had also been getting worse and worse since xf86-video-nv was abandoned so naturally not many people in the DragonFly community bought Nvidia hardware and interest in Nouveau is relatively low. I played with it a bit but my hands are currently full updating and fixing the bugs in drm/i915 and the DragonFly Linux compatibility layer. I see, sorry. I guess I just interpreted it like that... Good luck! ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] NOUVEAU(0): DRI3 on EXA enabled
On 02/11/15 08:28, poma wrote: An interesting results. DRI2: $ vblank_mode=0 glxgears ATTENTION: default value of option vblank_mode overridden by environment. 6321 frames in 5.0 seconds = 1264.103 FPS 6380 frames in 5.0 seconds = 1275.943 FPS 6369 frames in 5.0 seconds = 1273.629 FPS 6377 frames in 5.0 seconds = 1275.322 FPS 6387 frames in 5.0 seconds = 1277.330 FPS 6407 frames in 5.0 seconds = 1281.337 FPS 6381 frames in 5.0 seconds = 1276.053 FPS 6410 frames in 5.0 seconds = 1281.855 FPS 6405 frames in 5.0 seconds = 1280.905 FPS 6378 frames in 5.0 seconds = 1275.599 FPS ^C ~ DRI3: $ cat /etc/X11/xorg.conf.d/nouveau-dri3.conf Section "Device" Identifier "Videocard0" Driver "nouveau" Option "DRI" "3" EndSection $ grep DRI3 /var/log/Xorg.0.log [ 4367.417] (II) NOUVEAU(0): DRI3 on EXA enabled For the record, the only acceptable way of checking for DRI3 is to run the program with LIBGL_DEBUG=verbose. Any other solution is wrong. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Nouveau for FreeBSD
On 04/11/15 11:58, Pierre Moreau wrote: Wasn't there some work being done by François Tigeot or Jean-Sébastien Pédron to port Nouveau to DragonFlyBSD/FreeBSD? Or at least they were talking about porting it at XDC 2014, no idea what the current status is. From what they said, they never really cared about nvidia because nvidia provides a binary driver that works, unlike intel and amd. I guess it will come some day! ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Nouveau for FreeBSD
On 04/11/15 10:38, C Bergström wrote: On Wed, Nov 4, 2015 at 3:33 PM, Martin Peres wrote: On 04/11/15 09:08, cbergst...@pathscale.com wrote: Is anyone actually and or actively working on this? Github.com/pathscale/pscnv is totally bitrot but waaay more portable base. Nouveau made hard Linux assumptions that will be difficult to overcome afaik. As pointed out by Ilia, this is not true anymore. Nouveau can also partially run in the userspace, the hard dependencies on Linux have been abstracted. Also, pscnv does not support the newest GPUs and receives no further development because everything it provided is now provided by Nouveau. I did mention pscnv was bitrot, but I'm not yet convinced that some of the key things which are implemented in nouveau were done to a comparable level of quality (would need to evaluate and don't have time/interest) --- To bring this conversation back on track - where would someone start *exactly* to port this to another OS? What kernel dependencies are there? This needs to be ported to the other OS, along with drm and ttm (which I believe have already been ported to all the BSDs): http://cgit.freedesktop.org/~darktama/nouveau/tree/lib/include/nvif/os.h ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Nouveau for FreeBSD
On 04/11/15 09:08, cbergst...@pathscale.com wrote: Is anyone actually and or actively working on this? Github.com/pathscale/pscnv is totally bitrot but waaay more portable base. Nouveau made hard Linux assumptions that will be difficult to overcome afaik. As pointed out by Ilia, this is not true anymore. Nouveau can also partially run in the userspace, the hard dependencies on Linux have been abstracted. Also, pscnv does not support the newest GPUs and receives no further development because everything it provided is now provided by Nouveau. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] PWM-based voltage management input clock
On 19/09/15 19:21, Martin Peres wrote: On 18/09/15 23:30, Andy Ritger wrote: Thanks, Martin. I'll try to follow up on this next week and get you an answer. What GPUs have you observed this on? Thanks Andy, As far as I can tell, it is the case for all GPUs using the PWM-based voltage management. To be more specific, we have seen this behaviour on a GK106 (mobile), a GM117 and a GM204. I guess this has fell into the cracks :) Any updates on this? Thanks, Martin ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/2] clk/gf100: allow users to enable reclocking
On 24/09/15 00:20, Samuel Pitoiset wrote: Only the core clock is currently supported. Signed-off-by: Samuel Pitoiset --- drm/nouveau/nvkm/subdev/clk/gf100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm/subdev/clk/gf100.c b/drm/nouveau/nvkm/subdev/clk/gf100.c index a52b7e7..807305a 100644 --- a/drm/nouveau/nvkm/subdev/clk/gf100.c +++ b/drm/nouveau/nvkm/subdev/clk/gf100.c @@ -462,5 +462,5 @@ gf100_clk_new(struct nvkm_device *device, int index, struct nvkm_clk **pclk) return -ENOMEM; *pclk = &clk->base; - return nvkm_clk_ctor(&gf100_clk, device, index, false, &clk->base); + return nvkm_clk_ctor(&gf100_clk, device, index, true, &clk->base); } What changed that suddenly made reclocking OK? You really need to prove it is and a few hours of testing are not enough ;) Make sure that the clock tree is parsed correctly, then programmed correctly. Make sure that reclocking while the card is being used is also kind of stable, at least on your card. After that, you may enable it and test on more Fermis. Until then, this patch is premature, at best. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2] ibus/gf100: increase wait timeout to avoid read faults
On 24/09/15 00:01, Samuel Pitoiset wrote:
Increase clock timeout of some unknown engines in order to avoid failure
at high gpcclk rate.
This fixes IBUS read faults on my GF119 when reclocking is manually
enabled. Note that memory reclocking is completely broken and NvMemExec
has to be disabled to allow core clock reclocking only.
Signed-off-by: Samuel Pitoiset
---
V2: increase mask for the gf100 case
drm/nouveau/include/nvkm/subdev/ibus.h | 1 +
drm/nouveau/nvkm/engine/device/base.c | 4 +--
drm/nouveau/nvkm/subdev/ibus/Kbuild| 1 +
drm/nouveau/nvkm/subdev/ibus/gf100.c | 17 ++--
drm/nouveau/nvkm/subdev/ibus/gf117.c | 51 ++
drm/nouveau/nvkm/subdev/ibus/priv.h| 7 +
6 files changed, 77 insertions(+), 4 deletions(-)
create mode 100644 drm/nouveau/nvkm/subdev/ibus/gf117.c
create mode 100644 drm/nouveau/nvkm/subdev/ibus/priv.h
diff --git a/drm/nouveau/include/nvkm/subdev/ibus.h
b/drm/nouveau/include/nvkm/subdev/ibus.h
index 9d512cd..c4dcd26 100644
--- a/drm/nouveau/include/nvkm/subdev/ibus.h
+++ b/drm/nouveau/include/nvkm/subdev/ibus.h
@@ -3,6 +3,7 @@
#include
int gf100_ibus_new(struct nvkm_device *, int, struct nvkm_subdev **);
+int gf117_ibus_new(struct nvkm_device *, int, struct nvkm_subdev **);
int gk104_ibus_new(struct nvkm_device *, int, struct nvkm_subdev **);
int gk20a_ibus_new(struct nvkm_device *, int, struct nvkm_subdev **);
#endif
diff --git a/drm/nouveau/nvkm/engine/device/base.c
b/drm/nouveau/nvkm/engine/device/base.c
index 952a508..83383bc 100644
--- a/drm/nouveau/nvkm/engine/device/base.c
+++ b/drm/nouveau/nvkm/engine/device/base.c
@@ -1595,7 +1595,7 @@ nvd7_chipset = {
.fuse = gf100_fuse_new,
.gpio = gf119_gpio_new,
.i2c = gf117_i2c_new,
- .ibus = gf100_ibus_new,
+ .ibus = gf117_ibus_new,
.imem = nv50_instmem_new,
.ltc = gf100_ltc_new,
.mc = gf100_mc_new,
@@ -1628,7 +1628,7 @@ nvd9_chipset = {
.fuse = gf100_fuse_new,
.gpio = gf119_gpio_new,
.i2c = gf119_i2c_new,
- .ibus = gf100_ibus_new,
+ .ibus = gf117_ibus_new,
.imem = nv50_instmem_new,
.ltc = gf100_ltc_new,
.mc = gf100_mc_new,
diff --git a/drm/nouveau/nvkm/subdev/ibus/Kbuild
b/drm/nouveau/nvkm/subdev/ibus/Kbuild
index a0b12d2..de888fa 100644
--- a/drm/nouveau/nvkm/subdev/ibus/Kbuild
+++ b/drm/nouveau/nvkm/subdev/ibus/Kbuild
@@ -1,3 +1,4 @@
nvkm-y += nvkm/subdev/ibus/gf100.o
+nvkm-y += nvkm/subdev/ibus/gf117.o
nvkm-y += nvkm/subdev/ibus/gk104.o
nvkm-y += nvkm/subdev/ibus/gk20a.o
diff --git a/drm/nouveau/nvkm/subdev/ibus/gf100.c
b/drm/nouveau/nvkm/subdev/ibus/gf100.c
index 37a0496..6c61d54 100644
--- a/drm/nouveau/nvkm/subdev/ibus/gf100.c
+++ b/drm/nouveau/nvkm/subdev/ibus/gf100.c
@@ -21,7 +21,7 @@
*
* Authors: Ben Skeggs
*/
-#include
+#include "priv.h"
static void
gf100_ibus_intr_hub(struct nvkm_subdev *ibus, int i)
@@ -56,7 +56,7 @@ gf100_ibus_intr_gpc(struct nvkm_subdev *ibus, int i)
nvkm_mask(device, 0x128128 + (i * 0x0400), 0x0200, 0x);
}
-static void
+void
gf100_ibus_intr(struct nvkm_subdev *ibus)
{
struct nvkm_device *device = ibus->device;
@@ -92,8 +92,21 @@ gf100_ibus_intr(struct nvkm_subdev *ibus)
}
}
+static int
+gf100_ibus_init(struct nvkm_subdev *ibus)
+{
+ struct nvkm_device *device = ibus->device;
+ nvkm_mask(device, 0x122310, 0x0003, 0x0800);
+ nvkm_mask(device, 0x12232c, 0x0073, 0x00100064);
+ nvkm_mask(device, 0x122330, 0x0073, 0x00100064);
+ nvkm_mask(device, 0x122334, 0x0073, 0x00100064);
+ nvkm_mask(device, 0x122348, 0x0003, 0x0100);
+ return 0;
+}
# nvapeek -c1 0x122330
00122330: ff73
startx
# nvapeek -c1 0x122330
00122330: 00100064
Seems like the blob is not masking anything. Can you get rid of the
masks after you check that on all the domains?
+
static const struct nvkm_subdev_func
gf100_ibus = {
+ .init = gf100_ibus_init,
.intr = gf100_ibus_intr,
};
diff --git a/drm/nouveau/nvkm/subdev/ibus/gf117.c b/drm/nouveau/nvkm/subdev/ibus/gf117.c
new file mode 100644
index 000..f69f263
--- /dev/null
+++ b/drm/nouveau/nvkm/subdev/ibus/gf117.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright 2015 Samuel Pitosiet
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITH
Re: [Nouveau] PWM-based voltage management input clock
On 18/09/15 23:30, Andy Ritger wrote: Thanks, Martin. I'll try to follow up on this next week and get you an answer. What GPUs have you observed this on? Thanks Andy, As far as I can tell, it is the case for all GPUs using the PWM-based voltage management. To be more specific, we have seen this behaviour on a GK106 (mobile), a GM117 and a GM204. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] PWM-based voltage management input clock
Hello, We recently reverse engineered PWM-based voltage management but found an odity in the input clock frequency for the PWM controller. It seems like RM is assuming an input clock of 27.648 MHz instead of the actual 27MHz crystal found on the board. I thus have the following questions: - Is it a fixed value hardcoded in RM? (Current way it is done in Nouveau) - Should we use crystal_MHz * 1.024? I could spend some time hooking up my osciloscope to the VR to check if it is a bringup issue but it would not help Nouveau much as we need to reproduce the behaviour of RM anyway since this is the only validated configuration. Thanks in advance, Martin PS: The registers for this PWM controller are 0x20340 and 0x20344. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] gm204/6: add voltage control using the new gk104 volt class
I got confirmation that we can read and change the voltage with the same code.
The divider is also computed correctly on the gm204 we got our hands on.
Thanks to Yoshimo on IRC for executing the tests on his gm204!
Signed-off-by: Martin Peres
---
drm/nouveau/nvkm/engine/device/base.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drm/nouveau/nvkm/engine/device/base.c
b/drm/nouveau/nvkm/engine/device/base.c
index b324fd1..8e9b5e8 100644
--- a/drm/nouveau/nvkm/engine/device/base.c
+++ b/drm/nouveau/nvkm/engine/device/base.c
@@ -1982,6 +1982,7 @@ nv124_chipset = {
.pci = nv40_pci_new,
.pmu = gm107_pmu_new,
.timer = gk20a_timer_new,
+ .volt = gk104_volt_new,
.ce[0] = gm204_ce_new,
.ce[1] = gm204_ce_new,
.ce[2] = gm204_ce_new,
@@ -2012,6 +2013,7 @@ nv126_chipset = {
.pci = nv40_pci_new,
.pmu = gm107_pmu_new,
.timer = gk20a_timer_new,
+ .volt = gk104_volt_new,
.ce[0] = gm204_ce_new,
.ce[1] = gm204_ce_new,
.ce[2] = gm204_ce_new,
--
2.5.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 2/4] volt: add support for non-vid-based voltage controllers
This patch is not ideal but it definitely beats a rewrite of the current
interface and is very self-contained.
Signed-off-by: Martin Peres
---
drm/nouveau/nvkm/subdev/volt/base.c | 11 ++-
drm/nouveau/nvkm/subdev/volt/priv.h | 2 ++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drm/nouveau/nvkm/subdev/volt/base.c
b/drm/nouveau/nvkm/subdev/volt/base.c
index 4752dbd..50b5649 100644
--- a/drm/nouveau/nvkm/subdev/volt/base.c
+++ b/drm/nouveau/nvkm/subdev/volt/base.c
@@ -30,7 +30,12 @@
int
nvkm_volt_get(struct nvkm_volt *volt)
{
- int ret = volt->func->vid_get(volt), i;
+ int ret, i;
+
+ if (volt->func->volt_get)
+ return volt->func->volt_get(volt);
+
+ ret = volt->func->vid_get(volt);
if (ret >= 0) {
for (i = 0; i < volt->vid_nr; i++) {
if (volt->vid[i].vid == ret)
@@ -46,6 +51,10 @@ nvkm_volt_set(struct nvkm_volt *volt, u32 uv)
{
struct nvkm_subdev *subdev = &volt->subdev;
int i, ret = -EINVAL;
+
+ if (volt->func->volt_set)
+ return volt->func->volt_set(volt, uv);
+
for (i = 0; i < volt->vid_nr; i++) {
if (volt->vid[i].uv == uv) {
ret = volt->func->vid_set(volt, volt->vid[i].vid);
diff --git a/drm/nouveau/nvkm/subdev/volt/priv.h
b/drm/nouveau/nvkm/subdev/volt/priv.h
index 394f37c..cdb3d9f 100644
--- a/drm/nouveau/nvkm/subdev/volt/priv.h
+++ b/drm/nouveau/nvkm/subdev/volt/priv.h
@@ -9,6 +9,8 @@ int nvkm_volt_new_(const struct nvkm_volt_func *, struct
nvkm_device *,
int index, struct nvkm_volt **);
struct nvkm_volt_func {
+ int (*volt_get)(struct nvkm_volt *);
+ int (*volt_set)(struct nvkm_volt *, u32 uv);
int (*vid_get)(struct nvkm_volt *);
int (*vid_set)(struct nvkm_volt *, u8 vid);
int (*set_id)(struct nvkm_volt *, u8 id, int condition);
--
2.5.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 4/4] gm107: add voltage control using the new gk104 volt class
Let's ignore the other desktop Maxwells until I get my hands on one and confirm
that still can change the voltage.
Signed-off-by: Martin Peres
---
drm/nouveau/nvkm/engine/device/base.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drm/nouveau/nvkm/engine/device/base.c
b/drm/nouveau/nvkm/engine/device/base.c
index 7c35f1f..b324fd1 100644
--- a/drm/nouveau/nvkm/engine/device/base.c
+++ b/drm/nouveau/nvkm/engine/device/base.c
@@ -1952,6 +1952,7 @@ nv117_chipset = {
.pmu = gm107_pmu_new,
.therm = gm107_therm_new,
.timer = gk20a_timer_new,
+ .volt = gk104_volt_new,
.ce[0] = gk104_ce_new,
.ce[2] = gk104_ce_new,
.disp = gm107_disp_new,
--
2.5.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 3/4] volt/gk104: add support for pwm and gpio modes
Most Keplers actually use the GPIO-based voltage management instead of the new
PWM-based one. Use the GPIO mode as a fallback as it already gracefully handles
the case where no GPIOs exist.
All the Maxwells seem to use the PWM method though.
Signed-off-by: Martin Peres
---
drm/nouveau/include/nvkm/subdev/bios/gpio.h | 1 +
drm/nouveau/include/nvkm/subdev/volt.h | 1 +
drm/nouveau/nvkm/engine/device/base.c | 14 ++--
drm/nouveau/nvkm/subdev/volt/Kbuild | 1 +
drm/nouveau/nvkm/subdev/volt/gk104.c| 118
drm/nouveau/nvkm/subdev/volt/priv.h | 4 +
6 files changed, 132 insertions(+), 7 deletions(-)
create mode 100644 drm/nouveau/nvkm/subdev/volt/gk104.c
diff --git a/drm/nouveau/include/nvkm/subdev/bios/gpio.h
b/drm/nouveau/include/nvkm/subdev/bios/gpio.h
index 33be260..a47d46d 100644
--- a/drm/nouveau/include/nvkm/subdev/bios/gpio.h
+++ b/drm/nouveau/include/nvkm/subdev/bios/gpio.h
@@ -15,6 +15,7 @@ enum dcb_gpio_func_name {
DCB_GPIO_VID5 = 0x74,
DCB_GPIO_VID6 = 0x75,
DCB_GPIO_VID7 = 0x76,
+ DCB_GPIO_VID_PWM = 0x81,
};
#define DCB_GPIO_LOG_DIR 0x02
diff --git a/drm/nouveau/include/nvkm/subdev/volt.h
b/drm/nouveau/include/nvkm/subdev/volt.h
index 5c8a3f1..b458d04 100644
--- a/drm/nouveau/include/nvkm/subdev/volt.h
+++ b/drm/nouveau/include/nvkm/subdev/volt.h
@@ -18,5 +18,6 @@ int nvkm_volt_get(struct nvkm_volt *);
int nvkm_volt_set_id(struct nvkm_volt *, u8 id, int condition);
int nv40_volt_new(struct nvkm_device *, int, struct nvkm_volt **);
+int gk104_volt_new(struct nvkm_device *, int, struct nvkm_volt **);
int gk20a_volt_new(struct nvkm_device *, int, struct nvkm_volt **);
#endif
diff --git a/drm/nouveau/nvkm/engine/device/base.c
b/drm/nouveau/nvkm/engine/device/base.c
index 94a906b..7c35f1f 100644
--- a/drm/nouveau/nvkm/engine/device/base.c
+++ b/drm/nouveau/nvkm/engine/device/base.c
@@ -1673,7 +1673,7 @@ nve4_chipset = {
.pmu = gk104_pmu_new,
.therm = gf119_therm_new,
.timer = nv41_timer_new,
- .volt = nv40_volt_new,
+ .volt = gk104_volt_new,
.ce[0] = gk104_ce_new,
.ce[1] = gk104_ce_new,
.ce[2] = gk104_ce_new,
@@ -1710,7 +1710,7 @@ nve6_chipset = {
.pmu = gk104_pmu_new,
.therm = gf119_therm_new,
.timer = nv41_timer_new,
- .volt = nv40_volt_new,
+ .volt = gk104_volt_new,
.ce[0] = gk104_ce_new,
.ce[1] = gk104_ce_new,
.ce[2] = gk104_ce_new,
@@ -1747,7 +1747,7 @@ nve7_chipset = {
.pmu = gf119_pmu_new,
.therm = gf119_therm_new,
.timer = nv41_timer_new,
- .volt = nv40_volt_new,
+ .volt = gk104_volt_new,
.ce[0] = gk104_ce_new,
.ce[1] = gk104_ce_new,
.ce[2] = gk104_ce_new,
@@ -1808,7 +1808,7 @@ nvf0_chipset = {
.pmu = gk110_pmu_new,
.therm = gf119_therm_new,
.timer = nv41_timer_new,
- .volt = nv40_volt_new,
+ .volt = gk104_volt_new,
.ce[0] = gk104_ce_new,
.ce[1] = gk104_ce_new,
.ce[2] = gk104_ce_new,
@@ -1844,7 +1844,7 @@ nvf1_chipset = {
.pmu = gk110_pmu_new,
.therm = gf119_therm_new,
.timer = nv41_timer_new,
- .volt = nv40_volt_new,
+ .volt = gk104_volt_new,
.ce[0] = gk104_ce_new,
.ce[1] = gk104_ce_new,
.ce[2] = gk104_ce_new,
@@ -1880,7 +1880,7 @@ nv106_chipset = {
.pmu = gk208_pmu_new,
.therm = gf119_therm_new,
.timer = nv41_timer_new,
- .volt = nv40_volt_new,
+ .volt = gk104_volt_new,
.ce[0] = gk104_ce_new,
.ce[1] = gk104_ce_new,
.ce[2] = gk104_ce_new,
@@ -1916,7 +1916,7 @@ nv108_chipset = {
.pmu = gk208_pmu_new,
.therm = gf119_therm_new,
.timer = nv41_timer_new,
- .volt = nv40_volt_new,
+ .volt = gk104_volt_new,
.ce[0] = gk104_ce_new,
.ce[1] = gk104_ce_new,
.ce[2] = gk104_ce_new,
diff --git a/drm/nouveau/nvkm/subdev/volt/Kbuild
b/drm/nouveau/nvkm/subdev/volt/Kbuild
index 6b46ff4..b035c6e 100644
--- a/drm/nouveau/nvkm/subdev/volt/Kbuild
+++ b/drm/nouveau/nvkm/subdev/volt/Kbuild
@@ -1,4 +1,5 @@
nvkm-y += nvkm/subdev/volt/base.o
nvkm-y += nvkm/subdev/volt/gpio.o
nvkm-y += nvkm/subdev/volt/nv40.o
+nvkm-y += nvkm/subdev/volt/gk104.o
nvkm-y += nvkm/subdev/volt/gk20a.o
diff --git a/drm/nouveau/nvkm/subdev/volt/gk104.c
b/drm/nouveau/nvkm/subdev/volt/gk104.c
new file mode 100644
index 000..0d28be6
--- /dev/null
+++ b/drm/nouveau/nvkm/subdev/volt/gk104.c
@@ -0,0 +1,118 @@
+/*
+ * Copyright 2015 Martin Peres
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and
[Nouveau] [PATCH 1/4] bios/volt: add support for pwm-based volt management
Signed-off-by: Martin Peres
---
drm/nouveau/include/nvkm/subdev/bios/volt.h | 15 ++-
drm/nouveau/nvkm/subdev/bios/volt.c | 17 +++--
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drm/nouveau/include/nvkm/subdev/bios/volt.h
b/drm/nouveau/include/nvkm/subdev/bios/volt.h
index eb2de4b..b0df610 100644
--- a/drm/nouveau/include/nvkm/subdev/bios/volt.h
+++ b/drm/nouveau/include/nvkm/subdev/bios/volt.h
@@ -1,11 +1,24 @@
#ifndef __NVBIOS_VOLT_H__
#define __NVBIOS_VOLT_H__
+
+enum nvbios_volt_type {
+ NVBIOS_VOLT_GPIO = 0,
+ NVBIOS_VOLT_PWM,
+};
+
struct nvbios_volt {
- u8 vidmask;
+ enum nvbios_volt_type type;
u32 min;
u32 max;
u32 base;
+
+ /* GPIO mode */
+ u8 vidmask;
s16 step;
+
+ /* PWM mode */
+ u32 pwm_freq;
+ u32 pwm_range;
};
u16 nvbios_volt_table(struct nvkm_bios *, u8 *ver, u8 *hdr, u8 *cnt, u8 *len);
diff --git a/drm/nouveau/nvkm/subdev/bios/volt.c
b/drm/nouveau/nvkm/subdev/bios/volt.c
index 615804c..6e0a336 100644
--- a/drm/nouveau/nvkm/subdev/bios/volt.c
+++ b/drm/nouveau/nvkm/subdev/bios/volt.c
@@ -73,15 +73,19 @@ nvbios_volt_parse(struct nvkm_bios *bios, u8 *ver, u8 *hdr,
u8 *cnt, u8 *len,
memset(info, 0x00, sizeof(*info));
switch (!!volt * *ver) {
case 0x12:
+ info->type= NVBIOS_VOLT_GPIO;
info->vidmask = nvbios_rd08(bios, volt + 0x04);
break;
case 0x20:
+ info->type= NVBIOS_VOLT_GPIO;
info->vidmask = nvbios_rd08(bios, volt + 0x05);
break;
case 0x30:
+ info->type= NVBIOS_VOLT_GPIO;
info->vidmask = nvbios_rd08(bios, volt + 0x04);
break;
case 0x40:
+ info->type= NVBIOS_VOLT_GPIO;
info->base= nvbios_rd32(bios, volt + 0x04);
info->step= nvbios_rd16(bios, volt + 0x08);
info->vidmask = nvbios_rd08(bios, volt + 0x0b);
@@ -90,11 +94,20 @@ nvbios_volt_parse(struct nvkm_bios *bios, u8 *ver, u8 *hdr,
u8 *cnt, u8 *len,
info->max = info->base;
break;
case 0x50:
- info->vidmask = nvbios_rd08(bios, volt + 0x06);
info->min = nvbios_rd32(bios, volt + 0x0a);
info->max = nvbios_rd32(bios, volt + 0x0e);
info->base= nvbios_rd32(bios, volt + 0x12) & 0x00ff;
- info->step= nvbios_rd16(bios, volt + 0x16);
+
+ /* offset 4 seems to be a flag byte */
+ if (nvbios_rd32(bios, volt + 0x4) & 1) {
+ info->type = NVBIOS_VOLT_PWM;
+ info->pwm_freq = nvbios_rd32(bios, volt + 0x5) / 1000;
+ info->pwm_range = nvbios_rd32(bios, volt + 0x16);
+ } else {
+ info->type = NVBIOS_VOLT_GPIO;
+ info->vidmask = nvbios_rd08(bios, volt + 0x06);
+ info->step = nvbios_rd16(bios, volt + 0x16);
+ }
break;
}
return volt;
--
2.5.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] Add Option "DRI3" to allow to disable DRI3 under EXA.
CURRENT >= + XORG_VERSION_NUMERIC(1,16,3,0,0)); + if (ret && !nouveau_dri3_screen_init(pScreen)) return FALSE; if (!nouveau_exa_init(pScreen)) I like the added verbosity and indeed, dri3 is not ready yet (I started working on it). I trust you for which version of the xserver is started working better and that you actually tested your code: Reviewed-by: Martin Peres ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa-dev] [PATCH v3 0/2] nouveau: support for custom VRAM domains
On 19/06/2015 19:27, Alexandre Courbot wrote: On Fri, Jun 19, 2015 at 9:38 PM, Ben Skeggs wrote: On 19 June 2015 at 21:51, Martin Peres wrote: On 19/06/2015 13:02, Alexandre Courbot wrote: New revision of this patchset that prevents VRAM objects from being allocated on VRAM-less systems like Tegra. This is required for Mesa to work on such systems. Changes since v2: - Use vram_size to detect systems without VRAM and set the correct domain instead of expecting each chip to set its domain explicitly. This question may have been asked a ton of times, but what is the difference with the nvac (Ion)? Would the nvac have some reserved memory for its usage by the bios which would then be used as "VRAM"? PFB on the dGPU IGPs has facilities to fake VRAM from an area of "stolen" system memory reserved by the SBIOS. GK20A/GM20B do not do this, and require direct (or, via a mmu, whatever) access to system memory. Exactly. While dGPU do actually carve out a range of system memory to be exclusively used as "fake" VRAM, Tegra GPUs have access to the whole system memory which is shared with the other IPs of the SoC, which requires a different management strategy. Hence the choice to simply wipe out the concept of VRAM and use everything as system memory. Very well, thanks Ben and Alexandre! The series is: Reviewed-by: Martin Peres ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa-dev] [PATCH v3 0/2] nouveau: support for custom VRAM domains
On 19/06/2015 13:02, Alexandre Courbot wrote: New revision of this patchset that prevents VRAM objects from being allocated on VRAM-less systems like Tegra. This is required for Mesa to work on such systems. Changes since v2: - Use vram_size to detect systems without VRAM and set the correct domain instead of expecting each chip to set its domain explicitly. This question may have been asked a ton of times, but what is the difference with the nvac (Ion)? Would the nvac have some reserved memory for its usage by the bios which would then be used as "VRAM"? In any case, the patchseries sounds simple-enough to be maintainable. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2] nouveau: add coherent BO attribute
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, Alexandre Courbot wrote: Add a flag allowing Nouveau to specify that an object should be coherent at allocation time. This is required for some class of objects like fences which are randomly-accessed by both the CPU and GPU. This flag instructs the kernel driver to make sure the object remains coherent even on architectures for which coherency is not guaranteed by the bus. Signed-off-by: Alexandre Courbot Reviewed-by: Ben Skeggs Pushed! Thanks! Should we also bump the ABI version or something? If you mean changing libdrm_nouveau.so.2 to .so.3 no! If you mean having something that pkg-config can pick up that's done automatically on every drm release. Sorry for not having been clear. I was talking about checking against the driver version to ensure it supports all the features that libdrm can throw at it. We increased the modules's version to 1.2.2 when adding the coherent flag: drm/nouveau/nouveau_drm.h: * 1.2.2: * - add NOUVEAU_GEM_DOMAIN_COHERENT flag That will be the job of mesa to check the DRM version, I would guess. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Self introduction Hans de Goede
On 26/05/15 10:29, Hans de Goede wrote: Hi All, Since I will be working on nouveau pretty much starting today I thought it would be good to write a quick self introduction. I'm an FOSS enthusiast / developer since 1996. I've written (and still maintain) various hwmon drivers, various USB webcam drivers, libv4l and libgphoto camlibs for photoframes which use a custom usb protocol and usb redirection over the network for qemu. And although not the original author I'm now a days a maintainer of libusb, usb-3 bulk streams support in the xhci driver, the uas driver, and libahci_platform. In my spare time I work on u-boot and Linux support for Allwinner ARM SoCs, I'm a u-boot maintainer for these, and maintain the sata, mmc and usb kernel drivers. About a year ago I joined the Red Hat graphics team, where my first task was to help to get libinput up to a level where it could be used as the input stack for Wayland. The work on this is winding down, so my next project is to help out with nouveau and here I am. My knowledge of GPU-s and basically anything 3d is quite limited atm, so I will likely be asking a lot of questions to get up to speed. I'll also join the #nouveau channel on irc, so I'll see you all there. Regards, Hans Hey Hans. That's very good news! Welcome to the project! Do you know if you are going to help mostly on the kernel or mesa side? Martin ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2] nouveau: add coherent BO attribute
On 21/05/2015 11:47, Ben Skeggs wrote: On 21 May 2015 at 16:08, Alexandre Courbot wrote: Add a flag allowing Nouveau to specify that an object should be coherent at allocation time. This is required for some class of objects like fences which are randomly-accessed by both the CPU and GPU. This flag instructs the kernel driver to make sure the object remains coherent even on architectures for which coherency is not guaranteed by the bus. Signed-off-by: Alexandre Courbot Reviewed-by: Ben Skeggs Pushed! ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nouveau: add coherent BO attribute
On 20/05/15 08:11, Alexandre Courbot wrote: On Fri, May 15, 2015 at 8:39 PM, Maarten Lankhorst wrote: Op 15-05-15 om 09:11 schreef Alexandre Courbot: Re-pinging Marteen on an email address that still exists :P On Wed, Apr 22, 2015 at 6:08 PM, Alexandre Courbot wrote: On Sun, Mar 15, 2015 at 5:41 PM, Alexandre Courbot wrote: On 03/14/2015 04:33 AM, Maarten Lankhorst wrote: Hey, Op 13-03-15 om 07:27 schreef Alexandre Courbot: Add a flag allowing Nouveau to specify that an object should be coherent at allocation time. This is required for some class of objects like fences which are randomly-accessed by both the CPU and GPU. This flag instructs the kernel driver to make sure the object remains coherent even on architectures for which coherency is not guaranteed by the bus. Signed-off-by: Alexandre Courbot I don't see a problem with this patch, but similar patches to intel to libdrm have been shot down when the changes weren't in an official kernel yet, so I think this should wait until the change is at least in drm-next. ;-) Sounds good. I will ping you again once the kernel change reaches -next. Hi Marteen, The kernel change required for this patch is now in -next. Do you think we can merge it now? I think it would be ok to merge now. Great - who could do this? :P I could do it. Please provide me with the patch with the necessary R-b and I can push it to our libdrm (and/or mesa). ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/2] nv04-nv40: don't attempt to do 32-bit shifts
On 19/05/15 23:28, Ilia Mirkin wrote:
A 32-bit shift is a no-op, which will also make the new planemask get
or'd with ~0, thus negating the usefulness of the subsequent
planemask != ~0 check. Only do this if it's a less-than-32-bit per pixel
format, in which case it will have the desired effect of setting the
high bits.
Signed-off-by: Ilia Mirkin
---
src/nv04_exa.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/nv04_exa.c b/src/nv04_exa.c
index 7a58dd7..d5dec68 100644
--- a/src/nv04_exa.c
+++ b/src/nv04_exa.c
@@ -49,7 +49,8 @@ NV04EXASetROP(PixmapPtr ppix, int subc, int mthd, int alu,
Pixel planemask)
NVPtr pNv = NVPTR(pScrn);
struct nouveau_pushbuf *push = pNv->pushbuf;
- planemask |= ~0 << ppix->drawable.bitsPerPixel;
+ if (ppix->drawable.bitsPerPixel < 32)
+ planemask |= ~0 << ppix->drawable.bitsPerPixel;
if (planemask != ~0 || alu != GXcopy) {
if (ppix->drawable.bitsPerPixel == 32)
return FALSE;
Both patches look good to me. Thanks for tracking those bugs down :)
Reviewed-by: Martin Peres
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GM206 support?
On 18/03/2015 00:59, Ilia Mirkin wrote: On Tue, Mar 17, 2015 at 6:40 PM, Andy Lutomirski wrote: On Tue, Mar 17, 2015 at 2:57 PM, Ilia Mirkin wrote: On Tue, Mar 17, 2015 at 5:52 PM, Andy Lutomirski wrote: On Fri, Feb 13, 2015 at 9:52 PM, Ilia Mirkin wrote: On Fri, Feb 13, 2015 at 8:59 PM, Andy Lutomirski wrote: My new GTX 960 (GM206, I think) says: [ 10.329351] nouveau ![ DEVICE][:09:00.0] unknown Maxwell chipset [ 10.329355] nouveau E[ DEVICE][:09:00.0] unknown chipset, 0x126010a1 [ 10.329356] nouveau E[ DRM] failed to create 0x0080, -22 [ 10.330129] nouveau: probe of :09:00.0 failed with error -22 Hacking up nouveau so that it treats it like a GM204 doesn't work. What happens if you just drop the 0x126 next to the 0x124 in engine/device/gm100.c ? Are there any near-term plans to support this card? I don't know of anyone with the hw... maybe Ben got one? If you're interested in helping, the kernel logs from the above experiment + an mmiotrace of the blob drivers (see https://wiki.ubuntu.com/X/MMIOTracing) + vbios (see http://nouveau.freedesktop.org/wiki/DumpingVideoBios/). I assume you're on a recent kernel? You need 3.19 for the GM204 stuff to work in the first place. Neither 3.19 nor 4.0-rcsomething works. I put an mmio trace (X startup and glxgears) and a vbios dump here: http://web.mit.edu/luto/www/GM206/ Stefan sent proper patches to get nouveau going on his GM206, which will make it into the next 4.0-rc. Here is a tree that is destined towards drm-fixes: http://cgit.freedesktop.org/nouveau/linux-2.6/log/?h=linux-4.0 Let us know if it makes the card work. (Definitely no acceleration without signed firmware for now though.) The driver loads and seems to work. Excellent! The nouveau X driver doesn't load, though. Yeah, xf86-video-nouveau has no support for the GM20x family? Note that even if it did load, you wouldn't get any acceleration -- may as well just use the 'xf86-video-modesetting' driver. I tried to use the nvidia firmware: [...] with: options nouveau config=NvGrUseFW=1 in my modprobe configuration, and that made no obvious difference, even in the kernel logs. Right, that's expected. GM20x requires signed firmware. We haven't even gotten as far as being able to figure out what all the *proprietary* firmware is, never mind even loading it. It doesn't show up in mmiotraces, probably read by the card directly out of system memory. It's a multi-stage process, complicating RE. The firmware that you've extracted is exclusively for video decoding acceleration. You could extract firmware from 325.15 which will include the pgraph fuc blobs too [which would get loaded by NvGrUseFW=1], but nothing that'll help you. This is something that the recent work done by Samuel could help. He got the nvidia driver to work in kvm and then managed to trace the MMIO operations. If the card really reads the fw from system memory, it should show up in his trace. More info: https://hakzsam.wordpress.com/2015/02/21/471/ ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] fuse/gm107: simplify the return logic
Spotted by coccinelle: drivers/gpu/drm/nouveau/core/subdev/fuse/gm107.c:50:5-8: WARNING: end returns can be simpified Signed-off-by: Martin Peres --- drm/nouveau/nvkm/subdev/fuse/gm107.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/fuse/gm107.c b/drm/nouveau/nvkm/subdev/fuse/gm107.c index ba19158..0b256aa 100644 --- a/drm/nouveau/nvkm/subdev/fuse/gm107.c +++ b/drm/nouveau/nvkm/subdev/fuse/gm107.c @@ -45,10 +45,8 @@ gm107_fuse_ctor(struct nvkm_object *parent, struct nvkm_object *engine, ret = nvkm_fuse_create(parent, engine, oclass, &priv); *pobject = nv_object(priv); - if (ret) - return ret; - return 0; + return ret; } struct nvkm_oclass -- 2.2.2 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH V2 1/4] clk: allow non-blocking for nouveau_clock_astate()
On 07/01/15 07:10, Vince Hsu wrote: Hello Ben and Martin, Any comments for this series? Thanks, Vince Hello Vince, I have not really settled yet, so I don't think I have the time to review your patches right now as I have more urgent personnal priorities. Sorry, hope to be available soon! Martin ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RESEND PATCH nouveau 3/3] volt: add support for GK20A
On 28/11/2014 12:13, Vince Hsu wrote: The voltage value are calculated by the hardware characterized result. Signed-off-by: Vince Hsu --- Resend this patch with the fuse change and proper patch prefix per Thierry's request. Since the voltage table really is per-chipset, it would be insane to add that to the DT. If it was not the case, it is still easier to move to the DT instead of doing the opposite. Acked-by: Martin Peres ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RESEND PATCH nouveau 2/3] volt: allow non-bios voltage scaling
On 29/11/2014 09:22, Alexandre Courbot wrote: On Fri, Nov 28, 2014 at 8:12 PM, Vince Hsu wrote: Signed-off-by: Vince Hsu Make sure you always write a short summary for your patches, even if the title sounds sufficient. I agree. Something like "Move the vbios parsing out of init() and call it conditionally if the platform has a vbios. Non-vbios platforms can use the ctor() to init the data structures.". At the very least this patch makes the code easier to read, so: Acked-by: Alexandre Courbot Acked-by: Martin Peres ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] idea of extracting microcode
On 24/11/14 11:19, Dave Airlie wrote: Hey, Probably mostly for Ben, but I had this idea that it might be possible to write a userspace wrapper for the binary driver that run as root could be used to do the card init for the current or even a fake GPU then produce traces to pull the firmwares out. Not sure how insane it is, vs having to mmiotrace, but I just thought I'd see if anyone had considered it. Dave. Hello Dave, For the moment, we have an even-better solution developed by Ilia. This script extracts firmwares from the blob's installer without having to run it further than decompressing it. Here it is: https://raw.githubusercontent.com/imirkin/re-vp2/master/extract_firmware.py And there is a package for archlinux here: https://aur.archlinux.org/packages/nouveau-fw/ This solution is not perfect but, at XDC2014, we discussed it with Andy Ritger from NVIDIA and we are looking into a way for them to release their firmwares separately from the blob for our usage (along with the rights to redistribute them). As for your proposal of faking the GPU, we would need to change the mmiotracing tool to fake any MMIO request and couple that with a minimal hw model of NVIDIA GPUs. That being done, we would still need a mmiotrace with the real card to produce the golden context (the initial values for the context-switched registers). In the end, i am not sure it is worth the effort as we will need to have most chipsets anyway for testing purposes... Martin ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Logo Nouveau
On 18/11/14 00:18, Christian Costa wrote: Hi Valeria, Very nice logo! Nice job! I like the ideas and the font. :) Just few remarks about the visual appearance: - A horizontally centered penguin would be better as the left part of the "n" appears thiner than the right one - The bottom line of the "e" appears a little short to me Thanks Christian Hi Valeria, Christian's comments are indeed true. Could you address those concerns for the next update? I know that the penguin is asymmetric so it is hard to horizontally centre it but instead of centring it at its base, could you try to move it so as the general mass is better centred? With this done, I guess delivering the logo as an svg file along with its licence (have you had time to look at the creative commons?) would be a great step. It would also be nice to have one logo without nouveau written (for presentations) and one logo for the wiki (to replace the freedesktop logo: http://nouveau.freedesktop.org/wiki/). Thanks again Valeria for your work! It is greatly appreciated :) Martin ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Logo Nouveau
On 18/11/14 01:20, Jean-Sébastien Pédron wrote: On 17.11.2014 21:55, Martin Peres wrote: I would like to address here the "BSD not wanted" argument that seems to be implied by having a Penguin in the logo: - Nouveau does not currently run on any other kernel but Linux. I know that the BSDs are interested in porting Nouveau to their OS and I'm happy they are doing so, but I do not think any real development will happen on BSD unless both communities change heavily; As a FreeBSD developer, I take no offense in this logo and find it very beautiful in fact :-) Beside being the Linux mascot, I think Tux often represents Free Software in people minds. Of course some users will think that Nouveau is specific to Linux when they see this logo, but the day we work on porting the driver, it's our job to communicate the fact that it works on FreeBSD too. I was sure you would not mind, but it's good to see it in public! All in all, the logo won't stop us from stealing Nouveau :-) I hope not! Indeed! Congratulations Valeria for your work! Agreed! Martin ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Logo Nouveau
On 16/11/14 21:03, valeria aguilera wrote: Dear community members, Im a graphic designer and for the last couple of months I have been working on a new logo for the Nouveau project. After sending preliminary designs to both Martin Peres and Ilia Mirkin, we have decided to share the logo in order to gather your feedback. I would like to highlight that the logo incorporates a penguin corresponding to the linux kernel components used to create this open source driver. The 3D cube/shape represents the 2D and 3D acceleration capability. The “n” simply stands for the first letter in Nouveau and the green colour was chosen because the driver is for NVIDIA video cards. Please provide Martin and Ilia with your comments and preferences, since they both have been the ones giving me the design requirements. Valeria Aguilera. Hi Valeria, Thanks for making this public! I would like to address here the "BSD not wanted" argument that seems to be implied by having a Penguin in the logo: - Nouveau does not currently run on any other kernel but Linux. I know that the BSDs are interested in porting Nouveau to their OS and I'm happy they are doing so, but I do not think any real development will happen on BSD unless both communities change heavily; - The architecture of Nouveau DRM has been thought to use as little dependencies to Linux as possible to ease porting (especially to work in the userspace). - Nouveau is under the MIT/X11 licence which is BSD-compatible! - Finally, historically, Nouveau has only been developed on Linux by Linux users. I personnally find the penguin extremely cute and I would rather want to keep it. I hope I have convinced you (and especially the BSD-hobbyists) that it does not mean we are hostile to BSD in any case! Cheers and thanks again for your contribution! Martin ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] SLI development
On 06/11/14 22:45, tonda.mi...@post.cz wrote: Hello, our company has several pieces of old graphics cards QUADRO FX 4500 and FX 5600 able to run in SLI. Is somebody interested in SLI development? TonyMi Hello Tony, I wanted to answer you on IRC but you had left already. Anyway, I am not really interested in working on SLI support, but I am interested in the FX 4500 as I do not have it yet. Would you like to lend/give us cards or provide remote access to them? The first would be much better than the latter :) Thanks, Martin ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] NVIDIA Falcon Microprocessor Security
Hi Andy,
On 26/09/2014 19:19, Andy Ritger wrote:
Hi, all.
Below is a link to a brief document describing some changes in NVIDIA
Falcon processors ("fuc", in Nouveau-speak, IIUC)
We actually renamed most of our docs to falcon :)
that happened in
Maxwell: certain aspects of the chip will only be available to Falcon
firmware images signed by NVIDIA. So far, the set of restricted things
is pretty small, but I expect this list will slowly grow over future
hardware generations.
ftp://download.nvidia.com/open-gpu-doc/Falcon-Security/1/Falcon-Security.html
I suspect this will not be the most popular decision, but it is the
direction the hardware is taking.
Thank you for the heads-up! We actually wondered yesterday about
what kind of operations were forbidden without a signed falcon.
On a slightly different note, we'd like to work out the best way to
make NVIDIA firmware images separately (from the rest of the driver)
available and officially redistributable for use by Nouveau. At this
point, it is mostly just a release engineering question, but I don't think
we'll have a lot of influence over the content: the engineers working on
Falcon microcode assume it changes in lock-step with NVIDIA's nvidia.ko,
so there are no backwards compatibility guarantees. How painful has
the lack of backwards compatibility been for Nouveau thus far?
If NVIDIA just released firmware binaries along side each NVIDIA GPU driver
release, would it be reasonable for Nouveau to pick and choose which
firmware you'd like promoted to, e.g.,
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/
?
Anyway, this might be a good topic to discuss at XDC. It looks I'll
see a lot of you then; I'm looking forward to it!
Yeah, this really seems like a very good discussion to have at XDC. I'll
find a room for us to sit and discuss the problem.
Thanks again and see you soon!
Martin
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] (no subject)
On 13/09/2014 17:32, Ilia Mirkin wrote: What problem are you trying to solve? Perhaps you can start by describing the symptoms, providing logs, etc? Ilia, That's the third time he contacts us to fix "bugs" without giving any details. He then refuses to answer back. He is either a troll or desperately trying to push patches with his name on it. In any case, this patch is utterly wrong as the ifs are not even conditions, they are assignments. Asd, please stop wasting our time and try trolling somewhere else. If you are not a troll, then answer us before sending another patch! Martin ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Extend reserved memory on 0xfc000000
Le 08/09/2014 11:12, asd a écrit : Hi This patch correct on usb keyboard acces on number when enter via Ctrl + Alt + F12 on vt after Xorg running.Without this patch when enter on vt vas unable to use numbers from NumLock an only numbers from main keyboard. nouveau [ DEVICE][:01:00.0] BOOT0 : 0x046f00a3 nouveau [ DEVICE][:01:00.0] Chipset: G72 (NV46) nouveau [ DEVICE][:01:00.0] Family : NV40 nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... nouveau [ VBIOS][:01:00.0] ... appears to be valid nouveau [ VBIOS][:01:00.0] using image from PRAMIN nouveau [ VBIOS][:01:00.0] BIT signature found nouveau [ VBIOS][:01:00.0] version 05.72.22.43.00 Seems like a useful patch but please clean it up the patch, many changes are unnecessary. Please also send the patch with git send-email so as we can comment on the patch inline :) ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH envytools] nvamemtiming: Handle target < initial case when iterating values
On 31/08/2014 17:20, Christian Costa wrote: Le 31/08/2014 17:18, Christian Costa a écrit : Le 31/08/2014 16:23, Martin Peres a écrit : On 31/08/2014 16:19, Christian Costa wrote: Le 31/08/2014 16:11, Martin Peres a écrit : On 31/08/2014 16:01, Christian Costa wrote: Le 31/08/2014 15:12, Martin Peres a écrit : On 31/08/2014 15:00, Christian Costa wrote: Otherwise some values are not tested at all. I would rather have a warning than the program doing stuff behind my back. This is a dev tool, dumb == good ;) But why didn't you call it Dumb mode rather that Deep mode. That way, I wouldn't have tried to use it and figure out what it does. ;p Target is supposed to be higher than initial! Initial == minimum safe timing. You just reversed the order, try: sudo nvamemtiming pramin 0x6a22 5 0 -d 3 Ok. It's intended then. Thanks! I totally agree that this tool is a little confusing. If you have suggestions on how to improve the usage doc, feel free to propose me something better :) fprintf(stderr, "\t-d timing_entry_high: For each indexes, iterate between the timing_entry and the timing_entry_high value (Deep mode)\n"); Speaking about this, this should be corrected to "For each index", no plural after each. I'll fix it right now. Ok. I will think about it. Some comments in the source code can help also to know what it does and what it is used for. Same for README. Btw, the plural of index is indices. Yeah, it was doubly wrong ;) ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH envytools] nvamemtiming: Handle target < initial case when iterating values
On 31/08/2014 16:19, Christian Costa wrote: Le 31/08/2014 16:11, Martin Peres a écrit : On 31/08/2014 16:01, Christian Costa wrote: Le 31/08/2014 15:12, Martin Peres a écrit : On 31/08/2014 15:00, Christian Costa wrote: Otherwise some values are not tested at all. I would rather have a warning than the program doing stuff behind my back. This is a dev tool, dumb == good ;) But why didn't you call it Dumb mode rather that Deep mode. That way, I wouldn't have tried to use it and figure out what it does. ;p Target is supposed to be higher than initial! Initial == minimum safe timing. You just reversed the order, try: sudo nvamemtiming pramin 0x6a22 5 0 -d 3 Ok. It's intended then. Thanks! I totally agree that this tool is a little confusing. If you have suggestions on how to improve the usage doc, feel free to propose me something better :) fprintf(stderr, "\t-d timing_entry_high: For each indexes, iterate between the timing_entry and the timing_entry_high value (Deep mode)\n"); Speaking about this, this should be corrected to "For each index", no plural after each. I'll fix it right now. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH envytools] nvamemtiming: Handle target < initial case when iterating values
On 31/08/2014 16:01, Christian Costa wrote: Le 31/08/2014 15:12, Martin Peres a écrit : On 31/08/2014 15:00, Christian Costa wrote: Otherwise some values are not tested at all. I would rather have a warning than the program doing stuff behind my back. This is a dev tool, dumb == good ;) But why didn't you call it Dumb mode rather that Deep mode. That way, I wouldn't have tried to use it and figure out what it does. ;p Target is supposed to be higher than initial! Initial == minimum safe timing. You just reversed the order, try: sudo nvamemtiming pramin 0x6a22 5 0 -d 3 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH envytools] nvbios: Add missing null byte to string read from file.
On 31/08/2014 15:00, Christian Costa wrote:
---
nvbios/nvbios.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/nvbios/nvbios.c b/nvbios/nvbios.c
index f7aafe3..28e62ad 100644
--- a/nvbios/nvbios.c
+++ b/nvbios/nvbios.c
@@ -774,11 +774,12 @@ int set_strap_from_string(const char* strap_s)
int set_strap_from_file(const char *path)
{
FILE *strapfile = NULL;
- char tmp[21];
+ char tmp[22];
strapfile = fopen(path, "r");
if (strapfile) {
- fread(tmp, 1, 21, strapfile);
+ size_t size = fread(tmp, 1, 21, strapfile);
+ tmp[size] = 0;
return set_strap_from_string(tmp);
}
Thanks, I pushed the first 3 patches!
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH envytools] nva: Add nvaforcetemp to git ignore and sort it for better update
Woops, my bad... Sorry! ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH envytools] nvamemtiming: Handle target < initial case when iterating values
On 31/08/2014 15:00, Christian Costa wrote: Otherwise some values are not tested at all. I would rather have a warning than the program doing stuff behind my back. This is a dev tool, dumb == good ;) ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH envytools] nvbios: Fix reading of ram_restrict_group_count.
On 30/08/2014 19:05, Christian Costa wrote:
The entry offset was use instead of the data it points to. Probably a
regression.
The files showing script parsing errors has been reduced from 410 to 6 with the
database of 505 vbios.
---
nvbios/mem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/nvbios/mem.c b/nvbios/mem.c
index 81f2d1b..e4797e3 100644
--- a/nvbios/mem.c
+++ b/nvbios/mem.c
@@ -232,11 +232,11 @@ envy_bios_parse_bit_M (struct envy_bios *bios, struct
envy_bios_bit_entry *bit)
if (bit->version == 1) {
if (bit->t_len >= 5) {
- bios_u8(bios, bit->offset+2, &ram_restrict_group_count);
+ bios_u8(bios, bit->t_offset+2,
&ram_restrict_group_count);
}
} else if (bit->version == 2) {
if (bit->t_len >= 3) {
- bios_u8(bios, bit->offset, &ram_restrict_group_count);
+ bios_u8(bios, bit->t_offset, &ram_restrict_group_count);
}
}
A very big thank you Christian for this fix! It had been bothering a few
of us but we never really
looked into it because we always was reminded of this bug while doing
something else.
I pushed all three patches! Looking forward to seeing what's next ;)
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH envytools] Fix range end to the last value of timing table.
On 25/08/2014 21:00, Christian Costa wrote: --- nva/set_timings.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nva/set_timings.c b/nva/set_timings.c index 7376486..985a707 100644 --- a/nva/set_timings.c +++ b/nva/set_timings.c @@ -506,7 +506,7 @@ shallow_dump(struct nvamemtiming_conf *conf) if (conf->range.start == (unsigned char) -1) conf->range.start = 0; if (conf->range.end == (unsigned char) -1) - conf->range.end = conf->vbios.timing_entry_length; + conf->range.end = conf->vbios.timing_entry_length-1; fprintf(stderr, "Shallow mode: Will iterate between %i and %i\n", conf->range.start, conf->range.end); Hey I don't like this patch because it would create an output difference between the deep and the shallow test. Please check and propose another patch. What are you trying to fix by the way? You don't like that range.end is not included? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH envytools] nva: Clean up nva tools doc
Whole serie applied (all 7 patches). Thank you again :) Looking at the patches, it would seem like you were fixing potential bugs. Remember that envytools is meant for developers and we like stuff to break in catastrophic ways when the vbios (for instance) does not follow our expectations. Of course, crashing or corruption is not acceptable, but I'm all for a good-old assert or at least big fat warnings. Just don't waste too much time sanitizing nvbios since it clearly isn't meant for production. Thanks again and congrats for actually reading the code and documentation before contributing! I wish you good luck in generating the nvc0 memory timings :) Martin PS: Sorry it took me so long... ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH envytools] nvbios: Write missing null terminating byte.
On 25/08/2014 20:58, Christian Costa wrote:
---
nvbios/nvbios.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/nvbios/nvbios.c b/nvbios/nvbios.c
index 4fc667b..7bb768a 100644
--- a/nvbios/nvbios.c
+++ b/nvbios/nvbios.c
@@ -797,9 +797,9 @@ void find_strap(char *filename) {
path = (char*) malloc(base_length + strlen(strap_filename)+1);
strncpy(path, filename, base_length);
- strncpy(path+base_length, strap_filename, strlen(strap_filename));
+ strncpy(path+base_length, strap_filename, strlen(strap_filename)+1);
- if(!set_strap_from_file(path))
+ if (!set_strap_from_file(path))
printf("Strap register found in '%s'\n", path);
free(path);
Looks good
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH envytools] nva: Clean up nva tools doc
On 25/08/2014 20:58, Christian Costa wrote: - Sort commands by name for easier update - Make more readable - Remove no more existing commands --- nva/README | 83 +- 1 file changed, 44 insertions(+), 39 deletions(-) diff --git a/nva/README b/nva/README index 625ea7c..d4347c5 100644 --- a/nva/README +++ b/nva/README @@ -3,7 +3,7 @@ registers. WARNING: these tools *can* and *will* hang your machine if you don't know what you're doing. Hardware destruction is likely also possible, although -no incidents are known to have happened yet. In most cases it's also not +no incident are known to have happened yet. In most cases it's also not IIRC, "0" is considered plural in English. I'm sure Ilia or Ben could give us a more definitive answer on this :) recommended to use these tools while a driver is active for a given card. All programs except nvalist take an optional -c parameter. @@ -13,43 +13,48 @@ by the nvalist program. The programs are: -nvalist: prints a list of cards - -nvapeek []: reads 32-bit MMIO register at . -If byte count is also given, reads all registers in range [address, address -+ byte count). - -nvapeek8 []: like nvapeek, but does 8-bit MMIO accesses - -nvapoke : writes a 32-bit to the MMIO register at -. - -nvapoke8 : like nvapoke, but does 8-bit MMIO access - -nvawatch [-t] : reads MMIO register at in a loop, prints -the value every time it changes. If -t is specified, prints a timestamp -and diff from the previous timestamp before the value. Never quits, needs -to be manually aborted. - -nvahammer : like nvapoke, but repeats the write in -an infinite loop. Needs to be manually aborted. - -nvagetbios [-s ]: extracts the card's VBIOS using the -method given as parameter and writes it to stdout. Method can be PROM or -PRAMIN. If method is not given, defaults to something sensible. - -nvafuzz []: writes random values to a register or -a register range in an infinite loop. Needs to be manually aborted. - -nvascan [-as] []: for each register in a range: -read it, write 0x, read it, write 0, read it, write back the -original value. Helpful to see the valid values for registers. If -s option -is passed, does a slow scan - waits and reads PMC.ID register between scans -to recover from errors caused by invalid register accesses. If -a option -is passed, does a cross-test on all registers in the range to detect aliased -addresses [not particularly reliable]. - -nvatiming: attempts to measure what frequency various units of the card are -running at by using misc tricks. +nvafuzz [] +Writes random values to a register or +a register range in an infinite loop. Needs to be manually aborted. + +nvagetbios [-s ] +Extracts the card's VBIOS using the +method given as parameter and writes it to stdout. Method can be PROM or +PRAMIN. If method is not given, defaults to something sensible. + +nvahammer +Like nvapoke, but repeats the write in +an infinite loop. Needs to be manually aborted. + +nvalist +Prints a list of cards + +nvapeek [] +Reads 32-bit MMIO register at . +If byte count is also given, reads all registers in range [address, address ++ byte count). + +nvapoke +Writes a 32-bit to the MMIO register at +. + +nvascan [-as] [] +For each register in a range: +read it, write 0x, read it, write 0, read it, write back the +original value. Helpful to see the valid values for registers. If -s option +is passed, does a slow scan - waits and reads PMC.ID register between scans +to recover from errors caused by invalid register accesses. If -a option +is passed, does a cross-test on all registers in the range to detect aliased +addresses [not particularly reliable]. + +nvatiming +Attempts to measure what frequency various units of the card are +running at by using misc tricks. + +nvawatch [-t] +Reads MMIO register at in a loop, prints +the value every time it changes. If -t is specified, prints a timestamp +and diff from the previous timestamp before the value. Never quits, needs +to be manually aborted. [XXX: document the remaining tools] Did you fix some spelling mistakes in while changing the order? I already suck at comparing lines that are one on top of the other, so I don't even want to try checking! ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH envytools] docs: Fix some spelling and remove some trailing spaces.
On 25/08/2014 20:58, Christian Costa wrote: --- docs/hw/fifo/intro.rst | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/hw/fifo/intro.rst b/docs/hw/fifo/intro.rst index 8b1d69d..0e023bf 100644 --- a/docs/hw/fifo/intro.rst +++ b/docs/hw/fifo/intro.rst @@ -10,7 +10,7 @@ FIFO overview Introduction -Commands to most of the engines are sent through a special engine caled PFIFO. +Commands to most of the engines are sent through a special engine called PFIFO. PFIFO maintains multiple fully independent command queues, known as "channels" or "FIFO"s. Each channel is controlled through a "channel control area", which is a region of MMIO [pre-NVC0] or VRAM [NVC0+]. PFIFO intercepts all accesses @@ -40,11 +40,11 @@ The engines that PFIFO controls on NV04:NVC0 are: == == === === Id Present on NameDescription == == === === -0 allSOFTWARENot really an engine, causes interrupt for each - command, can be used to execute driver functions - in sync with other commands. -1 all:ref:`PGRAPH ` Main engine of the card: 2d, 3d, compute. -2 NV31:NV98 :ref:`PMPEG `The PFIFO interface to VPE MPEG2 decoding engine. +0 allSOFTWARENot really an engine, causes interrupt for each + command, can be used to execute driver functions + in sync with other commands. +1 all:ref:`PGRAPH ` Main engine of the card: 2d, 3d, compute. +2 NV31:NV98 :ref:`PMPEG `The PFIFO interface to VPE MPEG2 decoding engine. NVA0:NVAA 3 NV40:NV84 :ref:`PME `VPE motion estimation engine. 4 NV41:NV84 :ref:`PVP1 ` VPE microcoded vector processor. @@ -64,10 +64,10 @@ The engines that PFIFO controls on NVC0- are: = == === === IdPresent on NameDescription = == === === -1fallSOFTWARENot really an engine, causes interrupt for each - command, can be used to execute driver functions - in sync with other commands. -0 all:ref:`PGRAPH ` Main engine of the card: 2d, 3d, compute. +1fallSOFTWARENot really an engine, causes interrupt for each + command, can be used to execute driver functions + in sync with other commands. +0 all:ref:`PGRAPH ` Main engine of the card: 2d, 3d, compute. 1 all:ref:`PVDEC `falcon-based microcoded video decoder. 2 all:ref:` ` falcon-based video post-processor. 3 all:ref:`PVLD ` falcon-based variable length decoder. @@ -93,7 +93,7 @@ The PFIFO can be split into roughly 4 pieces: - PFIFO puller: executes the commands, passes them to the proper engine, or to the driver. - PFIFO switcher: ticks out the time slices for the channels and saves / - restores the state of the channel between PFIFO registers and RAMFC + restores the state of the channels between PFIFO registers and RAMFC memory. A channel consists of the following: @@ -133,7 +133,7 @@ is being submitted. See :ref:`nv03-pfifo-dma` for details. NV04 PFIFO greatly enhanced the DMA mode and made it controllable directly through the channel control area. Thus, commands can now be submitted by -multiple applications simultanously, without coordination with each other +multiple applications simultaneously, without coordination with each other and without kernel's help. DMA mode is described in :ref:`fifo-dma-pusher`. NV50 introduced IB mode. IB mode is a modified version of DMA mode that, @@ -143,8 +143,8 @@ to stitch together parts of multiple memory areas into a single command stream memory written by earlier commands. IB mode is described along with DMA mode in :ref:`fifo-dma-pusher`. -NVC0 rearchitected the whole PFIFO, made it possible to have up to 3 channels -executing simultanously, and introduced a new DMA packet format. +NVC0 rearchitectured the whole PFIFO, made it possible to have up to 3 channels +executing simultaneously, and introduced a new DMA packet format. The commands, as stored in CACHE, are tuples of: @@ -180,12 +180,12 @@ and engine-specific documentation. Pre-NV1A, PFIFO treats everything as little-endian. NV1A intro
Re: [Nouveau] [PATCH envytools] demmio: Add decoding of some MEM_TIMINGS registers for NVC0.
On 25/08/2014 20:58, Christian Costa wrote: --- rnndb/memory/nvc0_pbfb.xml | 37 ++--- 1 file changed, 34 insertions(+), 3 deletions(-) diff --git a/rnndb/memory/nvc0_pbfb.xml b/rnndb/memory/nvc0_pbfb.xml index 500cea9..e006dbe 100644 --- a/rnndb/memory/nvc0_pbfb.xml +++ b/rnndb/memory/nvc0_pbfb.xml @@ -49,23 +49,54 @@ Most bitfields are unknown. -RAS# precharge. +RAS# Precharge. - Activate to precharge delay. +Activate to precharge delay. Refresh to activate delay. -Row cycle time. +Row Cycle time. + + + + +This, and the next 6 regs, are all related to memtimings. + A good place to read might be http://www.tweakers.fr/timings.html . + Most bitfields are unknown. + + +Row Cycle time. + + +Refresh to activate delay. + + +Activate to precharge delay. + + +RAS# to CAS# Delay. + +Row Cycle time. + + +CAS# Write Latency. + + +Write To Read delay. + + +Write Recovery time. + Thanks for the patch but where did you get this knowledge? By comparing with nv50 and the vbios table? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] subdev: add a pfuse subdev v2
We will use this subdev to disable temperature reading on cards that did not get a sensor calibration in the factory. v2: - rename "nouveau_fuse_rd32" to "gxXXX_fuse_rd32" as adviced by Christian Costa - fold the code a little as adviced by Emil Velikov Signed-off-by: Martin Peres --- configure.ac | 1 + drm/Kbuild | 4 ++ drm/core/include/subdev/fuse.h | 1 + drm/core/subdev/fuse/base.c| 1 + drm/core/subdev/fuse/g80.c | 1 + drm/core/subdev/fuse/gf100.c | 1 + drm/core/subdev/fuse/gm107.c | 1 + drm/core/subdev/fuse/priv.h| 1 + nvkm/engine/device/gm100.c | 2 + nvkm/engine/device/nv50.c | 15 nvkm/engine/device/nvc0.c | 10 + nvkm/engine/device/nve0.c | 8 nvkm/include/core/device.h | 1 + nvkm/include/subdev/fuse.h | 30 +++ nvkm/subdev/Makefile.am| 3 +- nvkm/subdev/fuse/Makefile.am | 8 nvkm/subdev/fuse/base.c| 54 +++ nvkm/subdev/fuse/g80.c | 81 + nvkm/subdev/fuse/gf100.c | 83 ++ nvkm/subdev/fuse/gm107.c | 66 + nvkm/subdev/fuse/priv.h| 9 + 21 files changed, 380 insertions(+), 1 deletion(-) create mode 12 drm/core/include/subdev/fuse.h create mode 12 drm/core/subdev/fuse/base.c create mode 12 drm/core/subdev/fuse/g80.c create mode 12 drm/core/subdev/fuse/gf100.c create mode 12 drm/core/subdev/fuse/gm107.c create mode 12 drm/core/subdev/fuse/priv.h create mode 100644 nvkm/include/subdev/fuse.h create mode 100644 nvkm/subdev/fuse/Makefile.am create mode 100644 nvkm/subdev/fuse/base.c create mode 100644 nvkm/subdev/fuse/g80.c create mode 100644 nvkm/subdev/fuse/gf100.c create mode 100644 nvkm/subdev/fuse/gm107.c create mode 100644 nvkm/subdev/fuse/priv.h diff --git a/configure.ac b/configure.ac index de27156..b4404a5 100644 --- a/configure.ac +++ b/configure.ac @@ -74,6 +74,7 @@ AC_OUTPUT( Makefile \ nvkm/subdev/clock/Makefile \ nvkm/subdev/devinit/Makefile \ nvkm/subdev/fb/Makefile \ + nvkm/subdev/fuse/Makefile \ nvkm/subdev/gpio/Makefile \ nvkm/subdev/i2c/Makefile \ nvkm/subdev/ibus/Makefile \ diff --git a/drm/Kbuild b/drm/Kbuild index c663181..37ab09b 100644 --- a/drm/Kbuild +++ b/drm/Kbuild @@ -127,6 +127,10 @@ nouveau-y += core/subdev/fb/ramgk20a.o nouveau-y += core/subdev/fb/ramgm107.o nouveau-y += core/subdev/fb/sddr3.o nouveau-y += core/subdev/fb/gddr5.o +nouveau-y += core/subdev/fuse/base.o +nouveau-y += core/subdev/fuse/g80.o +nouveau-y += core/subdev/fuse/gf100.o +nouveau-y += core/subdev/fuse/gm107.o nouveau-y += core/subdev/gpio/base.o nouveau-y += core/subdev/gpio/nv10.o nouveau-y += core/subdev/gpio/nv50.o diff --git a/drm/core/include/subdev/fuse.h b/drm/core/include/subdev/fuse.h new file mode 12 index 000..421fdd7 --- /dev/null +++ b/drm/core/include/subdev/fuse.h @@ -0,0 +1 @@ +../../../../nvkm/include/subdev/fuse.h \ No newline at end of file diff --git a/drm/core/subdev/fuse/base.c b/drm/core/subdev/fuse/base.c new file mode 12 index 000..b218313 --- /dev/null +++ b/drm/core/subdev/fuse/base.c @@ -0,0 +1 @@ +../../../../nvkm/subdev/fuse/base.c \ No newline at end of file diff --git a/drm/core/subdev/fuse/g80.c b/drm/core/subdev/fuse/g80.c new file mode 12 index 000..c805b0d --- /dev/null +++ b/drm/core/subdev/fuse/g80.c @@ -0,0 +1 @@ +../../../../nvkm/subdev/fuse/g80.c \ No newline at end of file diff --git a/drm/core/subdev/fuse/gf100.c b/drm/core/subdev/fuse/gf100.c new file mode 12 index 000..ad9411b --- /dev/null +++ b/drm/core/subdev/fuse/gf100.c @@ -0,0 +1 @@ +../../../../nvkm/subdev/fuse/gf100.c \ No newline at end of file diff --git a/drm/core/subdev/fuse/gm107.c b/drm/core/subdev/fuse/gm107.c new file mode 12 index 000..947b11c --- /dev/null +++ b/drm/core/subdev/fuse/gm107.c @@ -0,0 +1 @@ +../../../../nvkm/subdev/fuse/gm107.c \ No newline at end of file diff --git a/drm/core/subdev/fuse/priv.h b/drm/core/subdev/fuse/priv.h new file mode 12 index 000..b6dedaa --- /dev/null +++ b/drm/core/subdev/fuse/priv.h @@ -0,0 +1 @@ +../../../../nvkm/subdev/fuse/priv.h \ No newline at end of file diff --git a/nvkm/engine/device/gm100.c b/nvkm/engine/device/gm100.c index 9e9f567..6295668 100644 --- a/nvkm/engine/device/gm100.c +++ b/nvkm/engine/device/gm100.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include #include @@ -62,6 +63,7 @@ gm100_identify(struct nouveau_device *device) device->oclass[NVDEV_SUBDEV_VBIOS ] = &nouveau_bios_oclass; device->oclass[NVDEV_SUBDEV_GPIO ] = nve0_gpio_oclass; device->oclass[NVDEV_SUBDEV_I2C] = nvd0_i2c_oclass; +
Re: [Nouveau] [PATCH 1/3] subdev: add a pfuse subdev
On 25/08/2014 00:27, Christian Costa wrote: Hi Martin, I'm not very familiar with the function naming scheme but shouldn't nouveau_fuse_rd32 use the same prefix as _fuse_ctor instead of nouveau? Christian Hey Christian, You're right, I should have. It's not really a problem since the function is static. I'll send a v2 if Ben wants me to fix it :) Martin ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 3/3] therm/nv84+: do not expose non-calibrated internal temp sensor
Signed-off-by: Martin Peres
---
nvkm/subdev/therm/nv84.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/nvkm/subdev/therm/nv84.c b/nvkm/subdev/therm/nv84.c
index 38b16d9..14e2e09 100644
--- a/nvkm/subdev/therm/nv84.c
+++ b/nvkm/subdev/therm/nv84.c
@@ -33,7 +33,12 @@ struct nv84_therm_priv {
int
nv84_temp_get(struct nouveau_therm *therm)
{
- return nv_rd32(therm, 0x20400);
+ struct nouveau_fuse *fuse = nouveau_fuse(therm);
+
+ if (nv_ro32(fuse, 0x1a8) == 1)
+ return nv_rd32(therm, 0x20400);
+ else
+ return -ENODEV;
}
void
--
2.0.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 2/3] therm: make sure the temperature settings are sane on nv84+
One of my nv92 has a calibrated internal sensor but it displays 0°C
as the default values use sw calibration values to force the temperature
to 0.
Since we cannot read the temperature from the adt7473 present on this board,
let's re-enable the internal reading!
Signed-off-by: Martin Peres
---
nvkm/subdev/therm/nv84.c | 31 ++-
nvkm/subdev/therm/nva3.c | 2 ++
nvkm/subdev/therm/nvd0.c | 2 ++
nvkm/subdev/therm/priv.h | 1 +
4 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/nvkm/subdev/therm/nv84.c b/nvkm/subdev/therm/nv84.c
index 1d15c52..38b16d9 100644
--- a/nvkm/subdev/therm/nv84.c
+++ b/nvkm/subdev/therm/nv84.c
@@ -24,6 +24,7 @@
*/
#include "priv.h"
+#include
struct nv84_therm_priv {
struct nouveau_therm_priv base;
@@ -35,6 +36,19 @@ nv84_temp_get(struct nouveau_therm *therm)
return nv_rd32(therm, 0x20400);
}
+void
+nv84_sensor_setup(struct nouveau_therm *therm)
+{
+ struct nouveau_fuse *fuse = nouveau_fuse(therm);
+
+ /* enable temperature reading for cards with insane defaults */
+ if (nv_ro32(fuse, 0x1a8) == 1) {
+ nv_mask(therm, 0x20008, 0x80008000, 0x8000);
+ nv_mask(therm, 0x2000c, 0x8003, 0x);
+ mdelay(20); /* wait for the temperature to stabilize */
+ }
+}
+
static void
nv84_therm_program_alarms(struct nouveau_therm *therm)
{
@@ -171,6 +185,21 @@ nv84_therm_intr(struct nouveau_subdev *subdev)
}
static int
+nv84_therm_init(struct nouveau_object *object)
+{
+ struct nv84_therm_priv *priv = (void *)object;
+ int ret;
+
+ ret = nouveau_therm_init(&priv->base.base);
+ if (ret)
+ return ret;
+
+ nv84_sensor_setup(&priv->base.base);
+
+ return 0;
+}
+
+static int
nv84_therm_ctor(struct nouveau_object *parent,
struct nouveau_object *engine,
struct nouveau_oclass *oclass, void *data, u32 size,
@@ -228,7 +257,7 @@ nv84_therm_oclass = {
.ofuncs = &(struct nouveau_ofuncs) {
.ctor = nv84_therm_ctor,
.dtor = _nouveau_therm_dtor,
- .init = _nouveau_therm_init,
+ .init = nv84_therm_init,
.fini = nv84_therm_fini,
},
};
diff --git a/nvkm/subdev/therm/nva3.c b/nvkm/subdev/therm/nva3.c
index 0478b2e..7893357 100644
--- a/nvkm/subdev/therm/nva3.c
+++ b/nvkm/subdev/therm/nva3.c
@@ -51,6 +51,8 @@ nva3_therm_init(struct nouveau_object *object)
if (ret)
return ret;
+ nv84_sensor_setup(&priv->base.base);
+
/* enable fan tach, count revolutions per-second */
nv_mask(priv, 0x00e720, 0x0003, 0x0002);
if (tach->func != DCB_GPIO_UNUSED) {
diff --git a/nvkm/subdev/therm/nvd0.c b/nvkm/subdev/therm/nvd0.c
index 04bb84f..b70f7cc 100644
--- a/nvkm/subdev/therm/nvd0.c
+++ b/nvkm/subdev/therm/nvd0.c
@@ -150,6 +150,8 @@ nvd0_therm_ctor(struct nouveau_object *parent,
if (ret)
return ret;
+ nv84_sensor_setup(&priv->base.base);
+
priv->base.base.pwm_ctrl = nvd0_fan_pwm_ctrl;
priv->base.base.pwm_get = nvd0_fan_pwm_get;
priv->base.base.pwm_set = nvd0_fan_pwm_set;
diff --git a/nvkm/subdev/therm/priv.h b/nvkm/subdev/therm/priv.h
index 4262d1d..7dba8c2 100644
--- a/nvkm/subdev/therm/priv.h
+++ b/nvkm/subdev/therm/priv.h
@@ -145,6 +145,7 @@ int nv50_fan_pwm_get(struct nouveau_therm *, int, u32 *,
u32 *);
int nv50_fan_pwm_set(struct nouveau_therm *, int, u32, u32);
int nv50_fan_pwm_clock(struct nouveau_therm *, int);
int nv84_temp_get(struct nouveau_therm *therm);
+void nv84_sensor_setup(struct nouveau_therm *therm);
int nv84_therm_fini(struct nouveau_object *object, bool suspend);
int nva3_therm_fan_sense(struct nouveau_therm *);
--
2.0.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 1/3] subdev: add a pfuse subdev
We will use this subdev to disable temperature reading on cards that did not get a sensor calibration in the factory. Signed-off-by: Martin Peres --- configure.ac | 1 + drm/Kbuild | 4 ++ drm/core/include/subdev/fuse.h | 1 + drm/core/subdev/fuse/base.c| 1 + drm/core/subdev/fuse/g80.c | 1 + drm/core/subdev/fuse/gf100.c | 1 + drm/core/subdev/fuse/gm107.c | 1 + drm/core/subdev/fuse/priv.h| 1 + nvkm/engine/device/gm100.c | 2 + nvkm/engine/device/nv50.c | 15 nvkm/engine/device/nvc0.c | 10 + nvkm/engine/device/nve0.c | 8 nvkm/include/core/device.h | 1 + nvkm/include/subdev/fuse.h | 30 +++ nvkm/subdev/Makefile.am| 3 +- nvkm/subdev/fuse/Makefile.am | 8 nvkm/subdev/fuse/base.c| 62 +++ nvkm/subdev/fuse/g80.c | 81 + nvkm/subdev/fuse/gf100.c | 83 ++ nvkm/subdev/fuse/gm107.c | 66 + nvkm/subdev/fuse/priv.h| 9 + 21 files changed, 388 insertions(+), 1 deletion(-) create mode 12 drm/core/include/subdev/fuse.h create mode 12 drm/core/subdev/fuse/base.c create mode 12 drm/core/subdev/fuse/g80.c create mode 12 drm/core/subdev/fuse/gf100.c create mode 12 drm/core/subdev/fuse/gm107.c create mode 12 drm/core/subdev/fuse/priv.h create mode 100644 nvkm/include/subdev/fuse.h create mode 100644 nvkm/subdev/fuse/Makefile.am create mode 100644 nvkm/subdev/fuse/base.c create mode 100644 nvkm/subdev/fuse/g80.c create mode 100644 nvkm/subdev/fuse/gf100.c create mode 100644 nvkm/subdev/fuse/gm107.c create mode 100644 nvkm/subdev/fuse/priv.h diff --git a/configure.ac b/configure.ac index de27156..b4404a5 100644 --- a/configure.ac +++ b/configure.ac @@ -74,6 +74,7 @@ AC_OUTPUT( Makefile \ nvkm/subdev/clock/Makefile \ nvkm/subdev/devinit/Makefile \ nvkm/subdev/fb/Makefile \ + nvkm/subdev/fuse/Makefile \ nvkm/subdev/gpio/Makefile \ nvkm/subdev/i2c/Makefile \ nvkm/subdev/ibus/Makefile \ diff --git a/drm/Kbuild b/drm/Kbuild index c663181..37ab09b 100644 --- a/drm/Kbuild +++ b/drm/Kbuild @@ -127,6 +127,10 @@ nouveau-y += core/subdev/fb/ramgk20a.o nouveau-y += core/subdev/fb/ramgm107.o nouveau-y += core/subdev/fb/sddr3.o nouveau-y += core/subdev/fb/gddr5.o +nouveau-y += core/subdev/fuse/base.o +nouveau-y += core/subdev/fuse/g80.o +nouveau-y += core/subdev/fuse/gf100.o +nouveau-y += core/subdev/fuse/gm107.o nouveau-y += core/subdev/gpio/base.o nouveau-y += core/subdev/gpio/nv10.o nouveau-y += core/subdev/gpio/nv50.o diff --git a/drm/core/include/subdev/fuse.h b/drm/core/include/subdev/fuse.h new file mode 12 index 000..421fdd7 --- /dev/null +++ b/drm/core/include/subdev/fuse.h @@ -0,0 +1 @@ +../../../../nvkm/include/subdev/fuse.h \ No newline at end of file diff --git a/drm/core/subdev/fuse/base.c b/drm/core/subdev/fuse/base.c new file mode 12 index 000..b218313 --- /dev/null +++ b/drm/core/subdev/fuse/base.c @@ -0,0 +1 @@ +../../../../nvkm/subdev/fuse/base.c \ No newline at end of file diff --git a/drm/core/subdev/fuse/g80.c b/drm/core/subdev/fuse/g80.c new file mode 12 index 000..c805b0d --- /dev/null +++ b/drm/core/subdev/fuse/g80.c @@ -0,0 +1 @@ +../../../../nvkm/subdev/fuse/g80.c \ No newline at end of file diff --git a/drm/core/subdev/fuse/gf100.c b/drm/core/subdev/fuse/gf100.c new file mode 12 index 000..ad9411b --- /dev/null +++ b/drm/core/subdev/fuse/gf100.c @@ -0,0 +1 @@ +../../../../nvkm/subdev/fuse/gf100.c \ No newline at end of file diff --git a/drm/core/subdev/fuse/gm107.c b/drm/core/subdev/fuse/gm107.c new file mode 12 index 000..947b11c --- /dev/null +++ b/drm/core/subdev/fuse/gm107.c @@ -0,0 +1 @@ +../../../../nvkm/subdev/fuse/gm107.c \ No newline at end of file diff --git a/drm/core/subdev/fuse/priv.h b/drm/core/subdev/fuse/priv.h new file mode 12 index 000..b6dedaa --- /dev/null +++ b/drm/core/subdev/fuse/priv.h @@ -0,0 +1 @@ +../../../../nvkm/subdev/fuse/priv.h \ No newline at end of file diff --git a/nvkm/engine/device/gm100.c b/nvkm/engine/device/gm100.c index 9e9f567..6295668 100644 --- a/nvkm/engine/device/gm100.c +++ b/nvkm/engine/device/gm100.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include #include @@ -62,6 +63,7 @@ gm100_identify(struct nouveau_device *device) device->oclass[NVDEV_SUBDEV_VBIOS ] = &nouveau_bios_oclass; device->oclass[NVDEV_SUBDEV_GPIO ] = nve0_gpio_oclass; device->oclass[NVDEV_SUBDEV_I2C] = nvd0_i2c_oclass; + device->oclass[NVDEV_SUBDEV_FUSE ] = &gm107_fuse_oclass; device->oclass[NVDEV_SUBDEV_CLOCK ] = &nve0_clock_oclass; device
Re: [Nouveau] [PATCH 09/10] pwr/fuc: make $r1-$r10 registers callee-saved in kernel.fuc
No 10/10, I decided not to send it right before doing so. Sorry for the noise. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 08/10] pwr/fuc: add ld/st macros
From: Martin Peres Signed-off-by: Martin Peres --- nvkm/subdev/pwr/fuc/macros.fuc | 10 ++ 1 file changed, 10 insertions(+) diff --git a/nvkm/subdev/pwr/fuc/macros.fuc b/nvkm/subdev/pwr/fuc/macros.fuc index 9707e3f..96fc984 100644 --- a/nvkm/subdev/pwr/fuc/macros.fuc +++ b/nvkm/subdev/pwr/fuc/macros.fuc @@ -251,6 +251,16 @@ */ clear b32 $r0 #endif +#define st(size, addr, reg) /* +*/ movw $r0 addr /* +*/ st size D[$r0] reg /* +*/ clear b32 $r0 + +#define ld(size, reg, addr) /* +*/ movw $r0 addr /* +*/ ld size reg D[$r0] /* +*/ clear b32 $r0 + // does a 64+64 -> 64 unsigned addition (C = A + B) #define addu64(reg_a_c_hi, reg_a_c_lo, b_hi, b_lo) /* */add b32 reg_a_c_lo b_lo /* -- 2.0.0 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 09/10] pwr/fuc: make $r1-$r10 registers callee-saved in kernel.fuc
From: Martin Peres
---
nvkm/subdev/pwr/fuc/kernel.fuc | 13 +
nvkm/subdev/pwr/fuc/nv108.fuc.h | 25 +++--
nvkm/subdev/pwr/fuc/nva3.fuc.h | 23 ++-
nvkm/subdev/pwr/fuc/nvc0.fuc.h | 23 ++-
nvkm/subdev/pwr/fuc/nvd0.fuc.h | 23 ++-
5 files changed, 54 insertions(+), 53 deletions(-)
diff --git a/nvkm/subdev/pwr/fuc/kernel.fuc b/nvkm/subdev/pwr/fuc/kernel.fuc
index 54276c9..5cf5be6 100644
--- a/nvkm/subdev/pwr/fuc/kernel.fuc
+++ b/nvkm/subdev/pwr/fuc/kernel.fuc
@@ -98,12 +98,16 @@ wr32:
// $r14 - ns
// $r0 - zero
nsec:
+ push $r9
+ push $r8
nv_iord($r8, NV_PPWR_TIMER_LOW)
nsec_loop:
nv_iord($r9, NV_PPWR_TIMER_LOW)
sub b32 $r9 $r8
cmp b32 $r9 $r14
bra l #nsec_loop
+ pop $r8
+ pop $r9
ret
// busy-wait for a period of time
@@ -115,6 +119,8 @@ nsec:
// $r11 - timeout (ns)
// $r0 - zero
wait:
+ push $r9
+ push $r8
nv_iord($r8, NV_PPWR_TIMER_LOW)
wait_loop:
nv_rd32($r10, $r14)
@@ -126,6 +132,8 @@ wait:
cmp b32 $r9 $r11
bra l #wait_loop
wait_done:
+ pop $r8
+ pop $r9
ret
// $r15 - current (kern)
@@ -460,6 +468,9 @@ send:
// $r14 - process
// $r0 - zero
recv:
+ push $r9
+ push $r8
+
ld b32 $r8 D[$r14 + #proc_qget]
ld b32 $r9 D[$r14 + #proc_qput]
bclr $flags $p1
@@ -492,6 +503,8 @@ recv:
bset $flags $p1
pop $r15
recv_done:
+ pop $r8
+ pop $r9
ret
init:
diff --git a/nvkm/subdev/pwr/fuc/nv108.fuc.h b/nvkm/subdev/pwr/fuc/nv108.fuc.h
index fe8dd23..82d6bbc 100644
--- a/nvkm/subdev/pwr/fuc/nv108.fuc.h
+++ b/nvkm/subdev/pwr/fuc/nv108.fuc.h
@@ -812,15 +812,18 @@ uint32_t nv108_pwr_code[] = {
0x7000d4f1,
0xf8f61bf4,
/* 0x005d: nsec */
- 0xcf2c0800,
-/* 0x0062: nsec_loop */
+ 0xf990f900,
+ 0xcf2c0880,
+/* 0x0066: nsec_loop */
0x2c090088,
0xbb0099cf,
0x9ea60298,
- 0xf8f61ef4,
-/* 0x0071: wait */
- 0xcf2c0800,
-/* 0x0076: wait_loop */
+ 0xfcf61ef4,
+ 0xf890fc80,
+/* 0x0079: wait */
+ 0xf990f900,
+ 0xcf2c0880,
+/* 0x0082: wait_loop */
0xeeb20088,
0x047e,
0xadfddab2,
@@ -865,13 +868,13 @@ uint32_t nv108_pwr_code[] = {
0xc40088cf,
0x0bf40289,
0x9b00b51f,
- 0x957e580e,
+ 0xa57e580e,
0x0998,
0x0096b09b,
0x000d0bf4,
0x0009f634,
0x09b504bd,
-/* 0x0125: intr_skip_watchdog */
+/* 0x0135: intr_skip_watchdog */
0x0089e49a,
0x360bf408,
0xcf068849,
@@ -1521,10 +1524,4 @@ uint32_t nv108_pwr_code[] = {
0x,
0x,
0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
};
diff --git a/nvkm/subdev/pwr/fuc/nva3.fuc.h b/nvkm/subdev/pwr/fuc/nva3.fuc.h
index 8e2ddd9..bf808e4 100644
--- a/nvkm/subdev/pwr/fuc/nva3.fuc.h
+++ b/nvkm/subdev/pwr/fuc/nva3.fuc.h
@@ -885,19 +885,22 @@ uint32_t nva3_pwr_code[] = {
0xd4f100dd,
0x1bf47000,
/* 0x007f: nsec */
- 0xf000f8f2,
+ 0xf900f8f2,
+ 0xf080f990,
0x84b62c87,
0x0088cf06,
-/* 0x0088: nsec_loop */
+/* 0x008c: nsec_loop */
0xb62c97f0,
0x99cf0694,
0x0298bb00,
0xf4069eb8,
- 0x00f8f11e,
-/* 0x009c: wait */
+ 0x80fcf11e,
+ 0x00f890fc,
+/* 0x00a4: wait */
+ 0x80f990f9,
0xb62c87f0,
0x88cf0684,
-/* 0x00a5: wait_loop */
+/* 0x00b1: wait_loop */
0x02eeb900,
0xb90421f4,
0xadfd02da,
@@ -948,13 +951,13 @@ uint32_t nva3_pwr_code[] = {
0xf40289c4,
0x0080230b,
0x58e7f09b,
- 0x98cb21f4,
+ 0x98db21f4,
0x96b09b09,
0x110bf400,
0xb63407f0,
0x09d00604,
0x8004bd00,
-/* 0x016e: intr_skip_watchdog */
+/* 0x017e: intr_skip_watchdog */
0x89e49a09,
0x0bf40800,
0x8897f148,
@@ -1650,10 +1653,4 @@ uint32_t nva3_pwr_code[] = {
0x,
0x,
0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
};
diff --git a/nvkm/subdev/pwr/fuc/nvc0.fuc.h b/nvkm/subdev/pwr/fuc/nvc0.fuc.h
index a0bd2c1..2371284 100644
--- a/nvkm/subdev/pwr/fuc/nvc0.fuc.h
+++ b/nvkm/subdev/pwr/fuc/nvc0.fuc.h
@@ -885,19 +885,22 @@ uint32_t nvc0_pwr_code[] = {
0xd4f100dd,
0x1bf47000,
/* 0x007f: nsec */
- 0xf000f8f2,
+ 0xf900f8f2,
+ 0xf080f990,
0x84b62c87,
0x0088cf06,
-/* 0x0088: nsec_loop */
+/* 0x008c: nsec_loop */
0xb62c97f0,
0x99cf0694,
0x0298bb00,
0xf4069eb8,
- 0x00f8f11e
[Nouveau] [PATCH 05/10] pwr: fix the timers implementation with concurent processes
From: Martin Peres
The problem with the current implementation is that adding a timer improperly
checked which process would time up first by not taking into account how much
time elapsed since their timer got scheduled. Rework the re-scheduling
decision t fix this.
The catch with this fix is that we are limited to scheduling timers of up to
2^31 ticks to avoid any potential overflow. Since we are unlikely to need to
wait for more than a second, this won't be a problem :)
Another possible fix would be to decrement the timeouts of all processes but
it would duplicate a lot of code and dealing with edge cases wasn't pretty
last time I checked.
Signed-off-by: Martin Peres
---
nvkm/subdev/pwr/fuc/kernel.fuc | 35 +-
nvkm/subdev/pwr/fuc/nv108.fuc.h | 308 ++--
nvkm/subdev/pwr/fuc/nva3.fuc.h | 364 --
nvkm/subdev/pwr/fuc/nvc0.fuc.h | 364 --
nvkm/subdev/pwr/fuc/nvd0.fuc.h | 1052 +++
5 files changed, 1133 insertions(+), 990 deletions(-)
diff --git a/nvkm/subdev/pwr/fuc/kernel.fuc b/nvkm/subdev/pwr/fuc/kernel.fuc
index 8f29bad..dd86439 100644
--- a/nvkm/subdev/pwr/fuc/kernel.fuc
+++ b/nvkm/subdev/pwr/fuc/kernel.fuc
@@ -245,9 +245,12 @@ intr:
// request the current process be sent a message after a timeout expires
//
// $r15 - current
-// $r14 - ticks
+// $r14 - ticks (make sure it is < 2^31 to avoid any possible overflow)
// $r0 - zero
timer:
+ push $r9
+ push $r8
+
// interrupts off to prevent racing with timer isr
bclr $flags ie0
@@ -255,13 +258,22 @@ timer:
ld b32 $r8 D[$r15 + #proc_time]
cmp b32 $r8 0
bra g #timer_done
- st b32 D[$r15 + #proc_time] $r14
- // halt watchdog timer temporarily and check for a pending
- // interrupt. if there's one already pending, we can just
- // bail since the timer isr will queue the next soonest
- // right after it's done
+ // halt watchdog timer temporarily
+ clear b32 $r8
nv_iowr(NV_PPWR_WATCHDOG_ENABLE, $r8)
+
+ // find out how much time elapsed since the last update
+ // of the watchdog and add this time to the wanted ticks
+ nv_iord($r8, NV_PPWR_WATCHDOG_TIME)
+ ld b32 $r9 D[$r0 + #time_prev]
+ sub b32 $r9 $r8
+ add b32 $r14 $r9
+ st b32 D[$r15 + #proc_time] $r14
+
+ // check for a pending interrupt. if there's one already
+ // pending, we can just bail since the timer isr will
+ // queue the next soonest right after it's done
nv_iord($r8, NV_PPWR_INTR)
and $r8 NV_PPWR_INTR_WATCHDOG
bra nz #timer_enable
@@ -272,10 +284,10 @@ timer:
cmp b32 $r14 $r0
bra e #timer_reset
cmp b32 $r14 $r8
- bra l #timer_done
- timer_reset:
- nv_iowr(NV_PPWR_WATCHDOG_TIME, $r14)
- st b32 D[$r0 + #time_prev] $r14
+ bra g #timer_enable
+ timer_reset:
+ nv_iowr(NV_PPWR_WATCHDOG_TIME, $r14)
+ st b32 D[$r0 + #time_prev] $r14
// re-enable the watchdog timer
timer_enable:
@@ -285,6 +297,9 @@ timer:
// interrupts back on
timer_done:
bset $flags ie0
+
+ pop $r8
+ pop $r9
ret
// send message to another process
diff --git a/nvkm/subdev/pwr/fuc/nv108.fuc.h b/nvkm/subdev/pwr/fuc/nv108.fuc.h
index 986495d..38b8ed4 100644
--- a/nvkm/subdev/pwr/fuc/nv108.fuc.h
+++ b/nvkm/subdev/pwr/fuc/nv108.fuc.h
@@ -24,8 +24,8 @@ uint32_t nv108_pwr_data[] = {
0x,
/* 0x0058: proc_list_head */
0x54534f48,
- 0x0379,
- 0x032a,
+ 0x0391,
+ 0x0342,
0x,
0x,
0x,
@@ -46,8 +46,8 @@ uint32_t nv108_pwr_data[] = {
0x,
0x,
0x584d454d,
- 0x0464,
- 0x0456,
+ 0x047c,
+ 0x046e,
0x,
0x,
0x,
@@ -68,8 +68,8 @@ uint32_t nv108_pwr_data[] = {
0x,
0x,
0x46524550,
- 0x0468,
- 0x0466,
+ 0x0480,
+ 0x047e,
0x,
0x,
0x,
@@ -90,8 +90,8 @@ uint32_t nv108_pwr_data[] = {
0x,
0x,
0x5f433249,
- 0x086c,
- 0x0713,
+ 0x0884,
+ 0x072b,
0x,
0x,
0x,
@@ -112,8 +112,8 @@ uint32_t nv108_pwr_data[] = {
0x,
0x,
0x54534554,
- 0x088d,
- 0x086e,
+ 0x08a5,
+ 0x0886,
0x,
0x,
0x,
@@ -134,8 +134,8 @@ uint32_t nv108_pwr_data[] = {
0x,
0x,
0x454c4449,
- 0x0898,
- 0x0896,
+ 0x08b0,
+ 0x08ae,
0x,
[Nouveau] [PATCH 07/10] pwr: add helpers for delay-to-ticks and ticks-to-delay
From: Martin Peres
Signed-off-by: Martin Peres
---
nvkm/subdev/pwr/fuc/kernel.fuc | 74 +++
nvkm/subdev/pwr/fuc/nv108.fuc |1 +
nvkm/subdev/pwr/fuc/nv108.fuc.h | 1105 ++--
nvkm/subdev/pwr/fuc/nva3.fuc|1 +
nvkm/subdev/pwr/fuc/nva3.fuc.h | 1191 ---
nvkm/subdev/pwr/fuc/nvc0.fuc|1 +
nvkm/subdev/pwr/fuc/nvc0.fuc.h | 1191 ---
nvkm/subdev/pwr/fuc/nvd0.fuc|1 +
nvkm/subdev/pwr/fuc/nvd0.fuc.h | 1165 --
9 files changed, 2446 insertions(+), 2284 deletions(-)
diff --git a/nvkm/subdev/pwr/fuc/kernel.fuc b/nvkm/subdev/pwr/fuc/kernel.fuc
index dd86439..54276c9 100644
--- a/nvkm/subdev/pwr/fuc/kernel.fuc
+++ b/nvkm/subdev/pwr/fuc/kernel.fuc
@@ -242,6 +242,80 @@ intr:
bclr $flags $p0
iret
+// calculate the number of ticks in the specified nanoseconds delay
+//
+// $r15 - current
+// $r14 - ns
+// $r14 - ticks (return)
+// $r0 - zero
+ticks_from_ns:
+ push $r12
+ push $r11
+
+ /* try not losing precision (multiply then divide) */
+ imm32($r13, HW_TICKS_PER_US)
+ call #mulu32_32_64
+
+ /* use an immeditate, it's ok because HW_TICKS_PER_US < 16 bits */
+ div $r12 $r12 1000
+
+ /* check if there wasn't any overflow */
+ cmpu b32 $r11 0
+ bra e #ticks_from_ns_quit
+
+ /* let's divide then multiply, too bad for the precision! */
+ div $r14 $r14 1000
+ imm32($r13, HW_TICKS_PER_US)
+ call #mulu32_32_64
+
+ /* this cannot overflow as long as HW_TICKS_PER_US < 1000 */
+
+ticks_from_ns_quit:
+ mov b32 $r14 $r12
+ pop $r11
+ pop $r12
+ ret
+
+// calculate the number of ticks in the specified microsecond delay
+//
+// $r15 - current
+// $r14 - us
+// $r14 - ticks (return)
+// $r0 - zero
+ticks_from_us:
+ push $r12
+ push $r11
+
+ /* simply multiply $us by HW_TICKS_PER_US */
+ imm32($r13, HW_TICKS_PER_US)
+ call #mulu32_32_64
+ mov b32 $r14 $r12
+
+ /* check if there wasn't any overflow */
+ cmpu b32 $r11 0
+ bra e #ticks_from_us_quit
+
+ /* Overflow! */
+ clear b32 $r14
+
+ticks_from_us_quit:
+ pop $r11
+ pop $r12
+ ret
+
+// calculate the number of ticks in the specified microsecond delay
+//
+// $r15 - current
+// $r14 - ticks
+// $r14 - us (return)
+// $r0 - zero
+ticks_to_us:
+ /* simply divide $ticks by HW_TICKS_PER_US */
+ imm32($r13, HW_TICKS_PER_US)
+ div $r14 $r14 $r13
+
+ ret
+
// request the current process be sent a message after a timeout expires
//
// $r15 - current
diff --git a/nvkm/subdev/pwr/fuc/nv108.fuc b/nvkm/subdev/pwr/fuc/nv108.fuc
index cdff6f6..b439519 100644
--- a/nvkm/subdev/pwr/fuc/nv108.fuc
+++ b/nvkm/subdev/pwr/fuc/nv108.fuc
@@ -23,6 +23,7 @@
*/
#define NVKM_PPWR_CHIPSET GK208
+#define HW_TICKS_PER_US 324
#define NVKM_FALCON_PC24
#define NVKM_FALCON_UNSHIFTED_IO
diff --git a/nvkm/subdev/pwr/fuc/nv108.fuc.h b/nvkm/subdev/pwr/fuc/nv108.fuc.h
index ae8850c..fe8dd23 100644
--- a/nvkm/subdev/pwr/fuc/nv108.fuc.h
+++ b/nvkm/subdev/pwr/fuc/nv108.fuc.h
@@ -24,8 +24,8 @@ uint32_t nv108_pwr_data[] = {
0x,
/* 0x0058: proc_list_head */
0x54534f48,
- 0x03e0,
- 0x0391,
+ 0x043b,
+ 0x03ec,
0x,
0x,
0x,
@@ -46,8 +46,8 @@ uint32_t nv108_pwr_data[] = {
0x,
0x,
0x584d454d,
- 0x04cb,
- 0x04bd,
+ 0x0526,
+ 0x0518,
0x,
0x,
0x,
@@ -68,8 +68,8 @@ uint32_t nv108_pwr_data[] = {
0x,
0x,
0x46524550,
- 0x04cf,
- 0x04cd,
+ 0x052a,
+ 0x0528,
0x,
0x,
0x,
@@ -90,8 +90,8 @@ uint32_t nv108_pwr_data[] = {
0x,
0x,
0x5f433249,
- 0x08d3,
- 0x077a,
+ 0x092e,
+ 0x07d5,
0x,
0x,
0x,
@@ -112,8 +112,8 @@ uint32_t nv108_pwr_data[] = {
0x,
0x,
0x54534554,
- 0x08f4,
- 0x08d5,
+ 0x094f,
+ 0x0930,
0x,
0x,
0x,
@@ -134,8 +134,8 @@ uint32_t nv108_pwr_data[] = {
0x,
0x,
0x454c4449,
- 0x08ff,
- 0x08fd,
+ 0x095a,
+ 0x0958,
0x,
0x,
0x,
@@ -229,20 +229,20 @@ uint32_t nv108_pwr_data[] = {
/* 0x0370: memx_func_head */
0x0001,
0x,
- 0x0410,
+ 0x046b,
/* 0x037c: memx_func_next */
0x0001,
0x00
[Nouveau] [PATCH 06/10] pwr: add some arith functions (mul32_32_64, subu64 and addu64)
From: Martin Peres
Signed-off-by: Martin Peres
---
drm/core/subdev/pwr/fuc/arith.fuc | 1 +
nvkm/subdev/pwr/Makefile.am | 3 +-
nvkm/subdev/pwr/fuc/arith.fuc | 94
nvkm/subdev/pwr/fuc/macros.fuc| 10 +
nvkm/subdev/pwr/fuc/nv108.fuc | 3 +
nvkm/subdev/pwr/fuc/nv108.fuc.h | 875 -
nvkm/subdev/pwr/fuc/nva3.fuc | 3 +
nvkm/subdev/pwr/fuc/nva3.fuc.h| 895 +++---
nvkm/subdev/pwr/fuc/nvc0.fuc | 3 +
nvkm/subdev/pwr/fuc/nvc0.fuc.h| 895 +++---
nvkm/subdev/pwr/fuc/nvd0.fuc | 3 +
nvkm/subdev/pwr/fuc/nvd0.fuc.h| 873 ++---
12 files changed, 1922 insertions(+), 1736 deletions(-)
create mode 12 drm/core/subdev/pwr/fuc/arith.fuc
create mode 100644 nvkm/subdev/pwr/fuc/arith.fuc
diff --git a/drm/core/subdev/pwr/fuc/arith.fuc
b/drm/core/subdev/pwr/fuc/arith.fuc
new file mode 12
index 000..240ced4
--- /dev/null
+++ b/drm/core/subdev/pwr/fuc/arith.fuc
@@ -0,0 +1 @@
+../../../../../nvkm/subdev/pwr/fuc/arith.fuc
\ No newline at end of file
diff --git a/nvkm/subdev/pwr/Makefile.am b/nvkm/subdev/pwr/Makefile.am
index 335decc..2bb4ca6 100644
--- a/nvkm/subdev/pwr/Makefile.am
+++ b/nvkm/subdev/pwr/Makefile.am
@@ -22,7 +22,8 @@ FUC_COMMON = fuc/os.h \
fuc/memx.fuc \
fuc/perf.fuc \
fuc/i2c_.fuc \
-fuc/test.fuc
+fuc/test.fuc \
+fuc/arith.fuc
fuc/nva3.fuc.h: fuc/nva3.fuc ${FUC_COMMON}
cpp -Ifuc -CC fuc/nva3.fuc | cpp \
diff --git a/nvkm/subdev/pwr/fuc/arith.fuc b/nvkm/subdev/pwr/fuc/arith.fuc
new file mode 100644
index 000..214a6d9
--- /dev/null
+++ b/nvkm/subdev/pwr/fuc/arith.fuc
@@ -0,0 +1,94 @@
+/*
+ * Copyright 2014 Martin Peres
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the folloing conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Martin Peres
+ */
+
+/**
+ * arith data segment
+ */
+#ifdef INCLUDE_PROC
+#endif
+
+#ifdef INCLUDE_DATA
+#endif
+
+/**
+ * arith code segment
+ */
+#ifdef INCLUDE_CODE
+
+// does a 32x32 -> 64 multiplication
+//
+// A * B = A_lo * B_lo
+//+ ( A_hi * B_lo ) << 16
+//+ ( A_lo * B_hi ) << 16
+//+ ( A_hi * B_hi ) << 32
+//
+// $r15 - current
+// $r14 - A
+// $r13 - B
+// $r12 - mul_lo (return)
+// $r11 - mul_hi (return)
+// $r0 - zero
+mulu32_32_64:
+ push $r1 // A_hi
+ push $r2 // B_hi
+ push $r3 // tmp0
+ push $r4 // tmp1
+
+ shr b32 $r1 $r14 16
+ shr b32 $r2 $r13 16
+
+ clear b32 $r12
+ clear b32 $r11
+
+ // A_lo * B_lo
+ mulu $r12 $r14 $r13
+
+ // ( A_hi * B_lo ) << 16
+ mulu $r3 $r1 $r13 // tmp0 = A_hi * B_lo
+ mov b32 $r4 $r3
+ and $r3 0x // tmp0 = tmp0_lo
+ shl b32 $r3 16
+ shr b32 $r4 16 // tmp1 = tmp0_hi
+ add b32 $r12 $r3
+ adc b32 $r11 $r4
+
+ // ( A_lo * B_hi ) << 16
+ mulu $r3 $r14 $r2 // tmp0 = A_lo * B_hi
+ mov b32 $r4 $r3
+ and $r3 0x // tmp0 = tmp0_lo
+ shl b32 $r3 16
+ shr b32 $r4 16 // tmp1 = tmp0_hi
+ add b32 $r12 $r3
+ adc b32 $r11 $r4
+
+ // ( A_hi * B_hi ) << 32
+ mulu $r3 $r1 $r2 // tmp0 = A_hi * B_hi
+ add b32 $r11 $r3
+
+ pop $r4
+ pop $r3
+ pop $r2
+ pop $r1
+ ret
+#endif
diff --git a/nvkm/subdev/pwr/fuc/macros.fuc b/nvkm/subdev/pwr/fuc/macros.fuc
index 5668e04..9707e3f 100644
--- a/nvkm/subdev/pwr/fuc/macros.fuc
+++ b/nvkm/subdev/pwr/fuc/macros.fuc
@@ -250,3 +250,13 @@
*/ st b32 D[$r0] re
[Nouveau] [PATCH 01/10] bios/fan: add support for maxwell's fan management table v2
Re-use the therm-exported fan structure with only two minor modifications:
- pwm_freq: u16 -> u32;
- add fan_type (toggle or PWM)
v2:
- Do not memset the table to 0 as it erases the pre-set default values
Signed-off-by: Martin Peres
---
drm/Kbuild | 1 +
drm/core/include/subdev/bios/fan.h | 1 +
drm/core/subdev/bios/fan.c | 1 +
nvkm/include/subdev/bios/fan.h | 8
nvkm/include/subdev/bios/therm.h | 10 +++-
nvkm/subdev/bios/Makefile.am | 3 +-
nvkm/subdev/bios/fan.c | 93 ++
7 files changed, 115 insertions(+), 2 deletions(-)
create mode 12 drm/core/include/subdev/bios/fan.h
create mode 12 drm/core/subdev/bios/fan.c
create mode 100644 nvkm/include/subdev/bios/fan.h
create mode 100644 nvkm/subdev/bios/fan.c
diff --git a/drm/Kbuild b/drm/Kbuild
index f5d7f7c..75aa5e3 100644
--- a/drm/Kbuild
+++ b/drm/Kbuild
@@ -52,6 +52,7 @@ nouveau-y += core/subdev/bios/vmap.o
nouveau-y += core/subdev/bios/volt.o
nouveau-y += core/subdev/bios/xpio.o
nouveau-y += core/subdev/bios/P0260.o
+nouveau-y += core/subdev/bios/fan.o
nouveau-y += core/subdev/bus/hwsq.o
nouveau-y += core/subdev/bus/nv04.o
nouveau-y += core/subdev/bus/nv31.o
diff --git a/drm/core/include/subdev/bios/fan.h
b/drm/core/include/subdev/bios/fan.h
new file mode 12
index 000..b56c338
--- /dev/null
+++ b/drm/core/include/subdev/bios/fan.h
@@ -0,0 +1 @@
+../../../../../nvkm/include/subdev/bios/fan.h
\ No newline at end of file
diff --git a/drm/core/subdev/bios/fan.c b/drm/core/subdev/bios/fan.c
new file mode 12
index 000..fe14fa4
--- /dev/null
+++ b/drm/core/subdev/bios/fan.c
@@ -0,0 +1 @@
+../../../../nvkm/subdev/bios/fan.c
\ No newline at end of file
diff --git a/nvkm/include/subdev/bios/fan.h b/nvkm/include/subdev/bios/fan.h
new file mode 100644
index 000..119d087
--- /dev/null
+++ b/nvkm/include/subdev/bios/fan.h
@@ -0,0 +1,8 @@
+#ifndef __NVBIOS_FAN_H__
+#define __NVBIOS_FAN_H__
+
+#include
+
+u16 nvbios_fan_parse(struct nouveau_bios *bios, struct nvbios_therm_fan *fan);
+
+#endif
diff --git a/nvkm/include/subdev/bios/therm.h b/nvkm/include/subdev/bios/therm.h
index 8dc5051..295d093 100644
--- a/nvkm/include/subdev/bios/therm.h
+++ b/nvkm/include/subdev/bios/therm.h
@@ -23,6 +23,12 @@ struct nvbios_therm_sensor {
struct nvbios_therm_threshold thrs_shutdown;
};
+enum nvbios_therm_fan_type {
+ NVBIOS_THERM_FAN_UNK = 0,
+ NVBIOS_THERM_FAN_TOGGLE = 1,
+ NVBIOS_THERM_FAN_PWM = 2,
+};
+
/* no vbios have more than 6 */
#define NOUVEAU_TEMP_FAN_TRIP_MAX 10
struct nouveau_therm_trip_point {
@@ -38,7 +44,9 @@ enum nvbios_therm_fan_mode {
};
struct nvbios_therm_fan {
- u16 pwm_freq;
+ enum nvbios_therm_fan_type type;
+
+ u32 pwm_freq;
u8 min_duty;
u8 max_duty;
diff --git a/nvkm/subdev/bios/Makefile.am b/nvkm/subdev/bios/Makefile.am
index 120b941..3ad1daf 100644
--- a/nvkm/subdev/bios/Makefile.am
+++ b/nvkm/subdev/bios/Makefile.am
@@ -22,6 +22,7 @@ libbios_la_SOURCES = base.c \
vmap.c \
volt.c \
xpio.c \
-P0260.c
+P0260.c \
+fan.c
include $(srcdir)/../Makefile.subdev
diff --git a/nvkm/subdev/bios/fan.c b/nvkm/subdev/bios/fan.c
new file mode 100644
index 000..e419892
--- /dev/null
+++ b/nvkm/subdev/bios/fan.c
@@ -0,0 +1,93 @@
+/*
+ * Copyright 2014 Martin Peres
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Martin Peres
+ */
+
+#include
+#include
+#include
+
+u16
+nvbios_fan_table(struct nouveau_bios *bios, u8 *ver, u8 *hdr, u8 *cnt, u8 *len)
+{
+ struct bit_entry bit_P;
+ u16 fan = 0x;
+
+ if (!bit_entry(bios, 'P', &bit_P)) {
+ if (bit_P.version == 2 && bit_P.length >= 0x5a)
+
[Nouveau] [PATCH 03/10] gm107/therm: add PWM fan support v2
v2: change the copyright ownership from "Nouveau Community" to myself, as per
Illia's recommendation.
Signed-off-by: Martin Peres
---
drm/Kbuild| 1 +
drm/core/subdev/therm/gm107.c | 1 +
nvkm/engine/device/gm100.c| 4 +-
nvkm/include/subdev/therm.h | 1 +
nvkm/subdev/therm/Makefile.am | 3 +-
nvkm/subdev/therm/fan.c | 9 -
nvkm/subdev/therm/gm107.c | 93 +++
nvkm/subdev/therm/nvd0.c | 2 +-
nvkm/subdev/therm/priv.h | 2 +
9 files changed, 109 insertions(+), 7 deletions(-)
create mode 12 drm/core/subdev/therm/gm107.c
create mode 100644 nvkm/subdev/therm/gm107.c
diff --git a/drm/Kbuild b/drm/Kbuild
index 75aa5e3..c663181 100644
--- a/drm/Kbuild
+++ b/drm/Kbuild
@@ -191,6 +191,7 @@ nouveau-y += core/subdev/therm/nv50.o
nouveau-y += core/subdev/therm/nv84.o
nouveau-y += core/subdev/therm/nva3.o
nouveau-y += core/subdev/therm/nvd0.o
+nouveau-y += core/subdev/therm/gm107.o
nouveau-y += core/subdev/timer/base.o
nouveau-y += core/subdev/timer/nv04.o
nouveau-y += core/subdev/timer/gk20a.o
diff --git a/drm/core/subdev/therm/gm107.c b/drm/core/subdev/therm/gm107.c
new file mode 12
index 000..aafc986
--- /dev/null
+++ b/drm/core/subdev/therm/gm107.c
@@ -0,0 +1 @@
+../../../../nvkm/subdev/therm/gm107.c
\ No newline at end of file
diff --git a/nvkm/engine/device/gm100.c b/nvkm/engine/device/gm100.c
index 377ec0b..136dd98 100644
--- a/nvkm/engine/device/gm100.c
+++ b/nvkm/engine/device/gm100.c
@@ -63,9 +63,7 @@ gm100_identify(struct nouveau_device *device)
device->oclass[NVDEV_SUBDEV_GPIO ] = nve0_gpio_oclass;
device->oclass[NVDEV_SUBDEV_I2C] = nvd0_i2c_oclass;
device->oclass[NVDEV_SUBDEV_CLOCK ] = &nve0_clock_oclass;
-#if 0
- device->oclass[NVDEV_SUBDEV_THERM ] = &nvd0_therm_oclass;
-#endif
+ device->oclass[NVDEV_SUBDEV_THERM ] = &gm107_therm_oclass;
device->oclass[NVDEV_SUBDEV_MXM] = &nv50_mxm_oclass;
device->oclass[NVDEV_SUBDEV_DEVINIT] = gm107_devinit_oclass;
device->oclass[NVDEV_SUBDEV_MC ] = gk20a_mc_oclass;
diff --git a/nvkm/include/subdev/therm.h b/nvkm/include/subdev/therm.h
index d4a6817..a437597 100644
--- a/nvkm/include/subdev/therm.h
+++ b/nvkm/include/subdev/therm.h
@@ -78,5 +78,6 @@ extern struct nouveau_oclass nv50_therm_oclass;
extern struct nouveau_oclass nv84_therm_oclass;
extern struct nouveau_oclass nva3_therm_oclass;
extern struct nouveau_oclass nvd0_therm_oclass;
+extern struct nouveau_oclass gm107_therm_oclass;
#endif
diff --git a/nvkm/subdev/therm/Makefile.am b/nvkm/subdev/therm/Makefile.am
index 460e4a0..b4f6da6 100644
--- a/nvkm/subdev/therm/Makefile.am
+++ b/nvkm/subdev/therm/Makefile.am
@@ -11,6 +11,7 @@ libtherm_la_SOURCES = base.c \
nv50.c \
nv84.c \
nva3.c \
- nvd0.c
+ nvd0.c \
+ gm107.c
include $(srcdir)/../Makefile.subdev
diff --git a/nvkm/subdev/therm/fan.c b/nvkm/subdev/therm/fan.c
index 016990a..402c9be 100644
--- a/nvkm/subdev/therm/fan.c
+++ b/nvkm/subdev/therm/fan.c
@@ -31,6 +31,8 @@
#include
#include
+#include
+
static int
nouveau_fan_update(struct nouveau_fan *fan, bool immediate, int target)
{
@@ -275,8 +277,11 @@ nouveau_therm_fan_ctor(struct nouveau_therm *therm)
/* other random init... */
nouveau_therm_fan_set_defaults(therm);
nvbios_perf_fan_parse(bios, &priv->fan->perf);
- if (nvbios_therm_fan_parse(bios, &priv->fan->bios))
- nv_error(therm, "parsing the thermal table failed\n");
+ if (nvbios_fan_parse(bios, &priv->fan->bios)) {
+ nv_debug(therm, "parsing the fan table failed\n");
+ if (nvbios_therm_fan_parse(bios, &priv->fan->bios))
+ nv_error(therm, "parsing both fan tables failed\n");
+ }
nouveau_therm_fan_safety_checks(therm);
return 0;
}
diff --git a/nvkm/subdev/therm/gm107.c b/nvkm/subdev/therm/gm107.c
new file mode 100644
index 000..2c58733
--- /dev/null
+++ b/nvkm/subdev/therm/gm107.c
@@ -0,0 +1,93 @@
+/*
+ * Copyright 2014 Martin Peres
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial
[Nouveau] [PATCH 04/10] ppwr: enable ppwr on gm107
For some reason, it is now required to wait a 20 µs after the 0x200 reset of the engine. Signed-off-by: Martin Peres --- nvkm/engine/device/gm100.c | 3 ++- nvkm/subdev/pwr/base.c | 3 +++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/nvkm/engine/device/gm100.c b/nvkm/engine/device/gm100.c index 136dd98..9e9f567 100644 --- a/nvkm/engine/device/gm100.c +++ b/nvkm/engine/device/gm100.c @@ -75,8 +75,9 @@ gm100_identify(struct nouveau_device *device) device->oclass[NVDEV_SUBDEV_INSTMEM] = nv50_instmem_oclass; device->oclass[NVDEV_SUBDEV_VM ] = &nvc0_vmmgr_oclass; device->oclass[NVDEV_SUBDEV_BAR] = &nvc0_bar_oclass; -#if 0 device->oclass[NVDEV_SUBDEV_PWR] = nv108_pwr_oclass; + +#if 0 device->oclass[NVDEV_SUBDEV_VOLT ] = &nv40_volt_oclass; #endif device->oclass[NVDEV_ENGINE_DMAOBJ ] = nvd0_dmaeng_oclass; diff --git a/nvkm/subdev/pwr/base.c b/nvkm/subdev/pwr/base.c index 69f1f34..477c9a2 100644 --- a/nvkm/subdev/pwr/base.c +++ b/nvkm/subdev/pwr/base.c @@ -204,6 +204,9 @@ _nouveau_pwr_init(struct nouveau_object *object) nv_mask(ppwr, 0x000200, 0x2000, 0x); nv_mask(ppwr, 0x000200, 0x2000, 0x2000); + /* At least one GM107 needs this delay after reset */ + udelay(20); + /* upload data segment */ nv_wr32(ppwr, 0x10a1c0, 0x0100); for (i = 0; i < impl->data.size / 4; i++) -- 2.0.0 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 02/10] therm/fan: do not use the pwm mode when the vbios tells us to use the toggle
Signed-off-by: Martin Peres
---
nvkm/subdev/therm/fanpwm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/nvkm/subdev/therm/fanpwm.c b/nvkm/subdev/therm/fanpwm.c
index 9a5c073..c629d7f 100644
--- a/nvkm/subdev/therm/fanpwm.c
+++ b/nvkm/subdev/therm/fanpwm.c
@@ -25,6 +25,8 @@
#include
#include
+#include
+#include
#include "priv.h"
@@ -86,11 +88,15 @@ nouveau_fanpwm_create(struct nouveau_therm *therm, struct
dcb_gpio_func *func)
{
struct nouveau_device *device = nv_device(therm);
struct nouveau_therm_priv *tpriv = (void *)therm;
+ struct nouveau_bios *bios = nouveau_bios(therm);
struct nouveau_fanpwm_priv *priv;
+ struct nvbios_therm_fan fan;
u32 divs, duty;
+ nvbios_fan_parse(bios, &fan);
+
if (!nouveau_boolopt(device->cfgopt, "NvFanPWM", func->param) ||
- !therm->pwm_ctrl ||
+ !therm->pwm_ctrl || fan.type == NVBIOS_THERM_FAN_TOGGLE ||
therm->pwm_get(therm, func->line, &divs, &duty) == -ENODEV)
return -ENODEV;
--
2.0.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 3/3] gm107/therm: add PWM fan support v2
v2: change the copyright ownership from "Nouveau Community" to myself, as per
Illia's recommendation.
Signed-off-by: Martin Peres
---
drm/Kbuild| 1 +
drm/core/subdev/therm/gm107.c | 1 +
nvkm/engine/device/gm100.c| 4 +-
nvkm/include/subdev/therm.h | 1 +
nvkm/subdev/therm/Makefile.am | 3 +-
nvkm/subdev/therm/fan.c | 9 -
nvkm/subdev/therm/gm107.c | 93 +++
nvkm/subdev/therm/nvd0.c | 2 +-
nvkm/subdev/therm/priv.h | 2 +
9 files changed, 109 insertions(+), 7 deletions(-)
create mode 12 drm/core/subdev/therm/gm107.c
create mode 100644 nvkm/subdev/therm/gm107.c
diff --git a/drm/Kbuild b/drm/Kbuild
index 75aa5e3..c663181 100644
--- a/drm/Kbuild
+++ b/drm/Kbuild
@@ -191,6 +191,7 @@ nouveau-y += core/subdev/therm/nv50.o
nouveau-y += core/subdev/therm/nv84.o
nouveau-y += core/subdev/therm/nva3.o
nouveau-y += core/subdev/therm/nvd0.o
+nouveau-y += core/subdev/therm/gm107.o
nouveau-y += core/subdev/timer/base.o
nouveau-y += core/subdev/timer/nv04.o
nouveau-y += core/subdev/timer/gk20a.o
diff --git a/drm/core/subdev/therm/gm107.c b/drm/core/subdev/therm/gm107.c
new file mode 12
index 000..aafc986
--- /dev/null
+++ b/drm/core/subdev/therm/gm107.c
@@ -0,0 +1 @@
+../../../../nvkm/subdev/therm/gm107.c
\ No newline at end of file
diff --git a/nvkm/engine/device/gm100.c b/nvkm/engine/device/gm100.c
index 377ec0b..136dd98 100644
--- a/nvkm/engine/device/gm100.c
+++ b/nvkm/engine/device/gm100.c
@@ -63,9 +63,7 @@ gm100_identify(struct nouveau_device *device)
device->oclass[NVDEV_SUBDEV_GPIO ] = nve0_gpio_oclass;
device->oclass[NVDEV_SUBDEV_I2C] = nvd0_i2c_oclass;
device->oclass[NVDEV_SUBDEV_CLOCK ] = &nve0_clock_oclass;
-#if 0
- device->oclass[NVDEV_SUBDEV_THERM ] = &nvd0_therm_oclass;
-#endif
+ device->oclass[NVDEV_SUBDEV_THERM ] = &gm107_therm_oclass;
device->oclass[NVDEV_SUBDEV_MXM] = &nv50_mxm_oclass;
device->oclass[NVDEV_SUBDEV_DEVINIT] = gm107_devinit_oclass;
device->oclass[NVDEV_SUBDEV_MC ] = gk20a_mc_oclass;
diff --git a/nvkm/include/subdev/therm.h b/nvkm/include/subdev/therm.h
index d4a6817..a437597 100644
--- a/nvkm/include/subdev/therm.h
+++ b/nvkm/include/subdev/therm.h
@@ -78,5 +78,6 @@ extern struct nouveau_oclass nv50_therm_oclass;
extern struct nouveau_oclass nv84_therm_oclass;
extern struct nouveau_oclass nva3_therm_oclass;
extern struct nouveau_oclass nvd0_therm_oclass;
+extern struct nouveau_oclass gm107_therm_oclass;
#endif
diff --git a/nvkm/subdev/therm/Makefile.am b/nvkm/subdev/therm/Makefile.am
index 460e4a0..b4f6da6 100644
--- a/nvkm/subdev/therm/Makefile.am
+++ b/nvkm/subdev/therm/Makefile.am
@@ -11,6 +11,7 @@ libtherm_la_SOURCES = base.c \
nv50.c \
nv84.c \
nva3.c \
- nvd0.c
+ nvd0.c \
+ gm107.c
include $(srcdir)/../Makefile.subdev
diff --git a/nvkm/subdev/therm/fan.c b/nvkm/subdev/therm/fan.c
index 016990a..402c9be 100644
--- a/nvkm/subdev/therm/fan.c
+++ b/nvkm/subdev/therm/fan.c
@@ -31,6 +31,8 @@
#include
#include
+#include
+
static int
nouveau_fan_update(struct nouveau_fan *fan, bool immediate, int target)
{
@@ -275,8 +277,11 @@ nouveau_therm_fan_ctor(struct nouveau_therm *therm)
/* other random init... */
nouveau_therm_fan_set_defaults(therm);
nvbios_perf_fan_parse(bios, &priv->fan->perf);
- if (nvbios_therm_fan_parse(bios, &priv->fan->bios))
- nv_error(therm, "parsing the thermal table failed\n");
+ if (nvbios_fan_parse(bios, &priv->fan->bios)) {
+ nv_debug(therm, "parsing the fan table failed\n");
+ if (nvbios_therm_fan_parse(bios, &priv->fan->bios))
+ nv_error(therm, "parsing both fan tables failed\n");
+ }
nouveau_therm_fan_safety_checks(therm);
return 0;
}
diff --git a/nvkm/subdev/therm/gm107.c b/nvkm/subdev/therm/gm107.c
new file mode 100644
index 000..2c58733
--- /dev/null
+++ b/nvkm/subdev/therm/gm107.c
@@ -0,0 +1,93 @@
+/*
+ * Copyright 2014 Martin Peres
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial
[Nouveau] [PATCH 3/3] gm107/therm: add PWM fan support
From: Martin Peres
Signed-off-by: Martin Peres
---
drm/Kbuild| 1 +
drm/core/subdev/therm/gm107.c | 1 +
nvkm/engine/device/gm100.c| 4 +-
nvkm/include/subdev/therm.h | 1 +
nvkm/subdev/therm/Makefile.am | 3 +-
nvkm/subdev/therm/fan.c | 9 -
nvkm/subdev/therm/gm107.c | 93 +++
nvkm/subdev/therm/nvd0.c | 2 +-
nvkm/subdev/therm/priv.h | 2 +
9 files changed, 109 insertions(+), 7 deletions(-)
create mode 12 drm/core/subdev/therm/gm107.c
create mode 100644 nvkm/subdev/therm/gm107.c
diff --git a/drm/Kbuild b/drm/Kbuild
index 75aa5e3..c663181 100644
--- a/drm/Kbuild
+++ b/drm/Kbuild
@@ -191,6 +191,7 @@ nouveau-y += core/subdev/therm/nv50.o
nouveau-y += core/subdev/therm/nv84.o
nouveau-y += core/subdev/therm/nva3.o
nouveau-y += core/subdev/therm/nvd0.o
+nouveau-y += core/subdev/therm/gm107.o
nouveau-y += core/subdev/timer/base.o
nouveau-y += core/subdev/timer/nv04.o
nouveau-y += core/subdev/timer/gk20a.o
diff --git a/drm/core/subdev/therm/gm107.c b/drm/core/subdev/therm/gm107.c
new file mode 12
index 000..aafc986
--- /dev/null
+++ b/drm/core/subdev/therm/gm107.c
@@ -0,0 +1 @@
+../../../../nvkm/subdev/therm/gm107.c
\ No newline at end of file
diff --git a/nvkm/engine/device/gm100.c b/nvkm/engine/device/gm100.c
index 377ec0b..136dd98 100644
--- a/nvkm/engine/device/gm100.c
+++ b/nvkm/engine/device/gm100.c
@@ -63,9 +63,7 @@ gm100_identify(struct nouveau_device *device)
device->oclass[NVDEV_SUBDEV_GPIO ] = nve0_gpio_oclass;
device->oclass[NVDEV_SUBDEV_I2C] = nvd0_i2c_oclass;
device->oclass[NVDEV_SUBDEV_CLOCK ] = &nve0_clock_oclass;
-#if 0
- device->oclass[NVDEV_SUBDEV_THERM ] = &nvd0_therm_oclass;
-#endif
+ device->oclass[NVDEV_SUBDEV_THERM ] = &gm107_therm_oclass;
device->oclass[NVDEV_SUBDEV_MXM] = &nv50_mxm_oclass;
device->oclass[NVDEV_SUBDEV_DEVINIT] = gm107_devinit_oclass;
device->oclass[NVDEV_SUBDEV_MC ] = gk20a_mc_oclass;
diff --git a/nvkm/include/subdev/therm.h b/nvkm/include/subdev/therm.h
index d4a6817..a437597 100644
--- a/nvkm/include/subdev/therm.h
+++ b/nvkm/include/subdev/therm.h
@@ -78,5 +78,6 @@ extern struct nouveau_oclass nv50_therm_oclass;
extern struct nouveau_oclass nv84_therm_oclass;
extern struct nouveau_oclass nva3_therm_oclass;
extern struct nouveau_oclass nvd0_therm_oclass;
+extern struct nouveau_oclass gm107_therm_oclass;
#endif
diff --git a/nvkm/subdev/therm/Makefile.am b/nvkm/subdev/therm/Makefile.am
index 460e4a0..b4f6da6 100644
--- a/nvkm/subdev/therm/Makefile.am
+++ b/nvkm/subdev/therm/Makefile.am
@@ -11,6 +11,7 @@ libtherm_la_SOURCES = base.c \
nv50.c \
nv84.c \
nva3.c \
- nvd0.c
+ nvd0.c \
+ gm107.c
include $(srcdir)/../Makefile.subdev
diff --git a/nvkm/subdev/therm/fan.c b/nvkm/subdev/therm/fan.c
index 016990a..402c9be 100644
--- a/nvkm/subdev/therm/fan.c
+++ b/nvkm/subdev/therm/fan.c
@@ -31,6 +31,8 @@
#include
#include
+#include
+
static int
nouveau_fan_update(struct nouveau_fan *fan, bool immediate, int target)
{
@@ -275,8 +277,11 @@ nouveau_therm_fan_ctor(struct nouveau_therm *therm)
/* other random init... */
nouveau_therm_fan_set_defaults(therm);
nvbios_perf_fan_parse(bios, &priv->fan->perf);
- if (nvbios_therm_fan_parse(bios, &priv->fan->bios))
- nv_error(therm, "parsing the thermal table failed\n");
+ if (nvbios_fan_parse(bios, &priv->fan->bios)) {
+ nv_debug(therm, "parsing the fan table failed\n");
+ if (nvbios_therm_fan_parse(bios, &priv->fan->bios))
+ nv_error(therm, "parsing both fan tables failed\n");
+ }
nouveau_therm_fan_safety_checks(therm);
return 0;
}
diff --git a/nvkm/subdev/therm/gm107.c b/nvkm/subdev/therm/gm107.c
new file mode 100644
index 000..e5015fa
--- /dev/null
+++ b/nvkm/subdev/therm/gm107.c
@@ -0,0 +1,93 @@
+/*
+ * Copyright 2014 Nouveau Community
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY
