From: "Nilawar, Badal" <badal.nilawar@intel.com>
To: Guenter Roeck <linux@roeck-us.net>,
Andi Shyti <andi.shyti@linux.intel.com>
Cc: linux-hwmon@vger.kernel.org, intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH v3 1/6] drm/xe/hwmon: Add HWMON infrastructure
Date: Fri, 4 Aug 2023 18:49:10 +0530 [thread overview]
Message-ID: <436c15bf-c031-9f72-c4cc-c7ff1600fdbf@intel.com> (raw)
In-Reply-To: <d8258e4d-4cc4-78e2-7858-78409f47774f@roeck-us.net>
Hi Guenter,
On 03-08-2023 04:42, Guenter Roeck wrote:
> On 8/2/23 15:40, Andi Shyti wrote:
>> Hi Badal,
>>
>> [...]
>>
>>> +struct xe_hwmon_data {
>>> + struct device *hwmon_dev;
>>> + struct xe_gt *gt;
>>> + char name[12];
>>> +};
>>> +
>>> +struct xe_hwmon {
>>> + struct xe_hwmon_data ddat;
>>> + struct mutex hwmon_lock;
>>> +};
>>
>> why do we need two structures here? Can we merge them?
>>
>
> A later patch adds multiple hwmon devices which makes use of it.
> I think that is flawed, and I am not inclined to accept it.
Is there any obvious reason that there shouldn't be multiple devices? In
i915 we are doing the same.
https://patchwork.freedesktop.org/patch/497324/?series=104278&rev=3
Regards,
Badal
>
> Guenter
>
>>> +static const struct hwmon_channel_info *hwmon_info[] = {
>>> + NULL
>>> +};
>>
>> just:
>>
>> static const struct hwmon_channel_info *hwmon_info[] = { };
>>
>> would do.
>>
>>> +static umode_t
>>> +hwmon_is_visible(const void *drvdata, enum hwmon_sensor_types type,
>>> + u32 attr, int channel)
>>> +{
>>> + struct xe_hwmon_data *ddat = (struct xe_hwmon_data *)drvdata;
>>> + int ret;
>>> +
>>> + xe_device_mem_access_get(gt_to_xe(ddat->gt));
>>> +
>>> + switch (type) {
>>> + default:
>>> + ret = 0;
>>> + break;
>>> + }
>>> +
>>> + xe_device_mem_access_put(gt_to_xe(ddat->gt));
>>> +
>>> + return ret;
>>
>> OK... we are forced to go through the switch and initialize ret.
>> Would be nicer to initialize ret to '0'... but it's not
>> important, feel free to ignore this comment if the compiler
>> doesn't complain.
>>
>>> +}
>>
>> [...]
>>
>>> + /* hwmon_dev points to device hwmon<i> */
>>> + hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat->name,
>>> + ddat,
>>> + &hwmon_chip_info,
>>> + NULL);
>>> + if (IS_ERR(hwmon_dev)) {
>>> + drm_warn(&xe->drm, "Fail to register xe hwmon, Err:%ld\n",
>>> PTR_ERR(hwmon_dev));
>>
>> I think this is better:
>>
>> drm_warn(&xe->drm, "Fail to register xe hwmon (%pe)\n", hwmon_dev);
>>
>>> + xe->hwmon = NULL;
>>> + return;
>>> + }
>>> +
>>> + ddat->hwmon_dev = hwmon_dev;
>>> +}
>>> +
>>> +void xe_hwmon_unregister(struct xe_device *xe)
>>> +{
>>> + xe->hwmon = NULL;
>>
>> I think this is not necessary. Will xe check for hwmon at some
>> point?
>>
>> Andi
>>
>>> +}
>
WARNING: multiple messages have this Message-ID (diff)
From: "Nilawar, Badal" <badal.nilawar@intel.com>
To: Guenter Roeck <linux@roeck-us.net>,
Andi Shyti <andi.shyti@linux.intel.com>
Cc: <intel-xe@lists.freedesktop.org>, <linux-hwmon@vger.kernel.org>,
<anshuman.gupta@intel.com>, <ashutosh.dixit@intel.com>,
<riana.tauro@intel.com>, <matthew.brost@intel.com>
Subject: Re: [PATCH v3 1/6] drm/xe/hwmon: Add HWMON infrastructure
Date: Fri, 4 Aug 2023 18:49:10 +0530 [thread overview]
Message-ID: <436c15bf-c031-9f72-c4cc-c7ff1600fdbf@intel.com> (raw)
In-Reply-To: <d8258e4d-4cc4-78e2-7858-78409f47774f@roeck-us.net>
Hi Guenter,
On 03-08-2023 04:42, Guenter Roeck wrote:
> On 8/2/23 15:40, Andi Shyti wrote:
>> Hi Badal,
>>
>> [...]
>>
>>> +struct xe_hwmon_data {
>>> + struct device *hwmon_dev;
>>> + struct xe_gt *gt;
>>> + char name[12];
>>> +};
>>> +
>>> +struct xe_hwmon {
>>> + struct xe_hwmon_data ddat;
>>> + struct mutex hwmon_lock;
>>> +};
>>
>> why do we need two structures here? Can we merge them?
>>
>
> A later patch adds multiple hwmon devices which makes use of it.
> I think that is flawed, and I am not inclined to accept it.
Is there any obvious reason that there shouldn't be multiple devices? In
i915 we are doing the same.
https://patchwork.freedesktop.org/patch/497324/?series=104278&rev=3
Regards,
Badal
>
> Guenter
>
>>> +static const struct hwmon_channel_info *hwmon_info[] = {
>>> + NULL
>>> +};
>>
>> just:
>>
>> static const struct hwmon_channel_info *hwmon_info[] = { };
>>
>> would do.
>>
>>> +static umode_t
>>> +hwmon_is_visible(const void *drvdata, enum hwmon_sensor_types type,
>>> + u32 attr, int channel)
>>> +{
>>> + struct xe_hwmon_data *ddat = (struct xe_hwmon_data *)drvdata;
>>> + int ret;
>>> +
>>> + xe_device_mem_access_get(gt_to_xe(ddat->gt));
>>> +
>>> + switch (type) {
>>> + default:
>>> + ret = 0;
>>> + break;
>>> + }
>>> +
>>> + xe_device_mem_access_put(gt_to_xe(ddat->gt));
>>> +
>>> + return ret;
>>
>> OK... we are forced to go through the switch and initialize ret.
>> Would be nicer to initialize ret to '0'... but it's not
>> important, feel free to ignore this comment if the compiler
>> doesn't complain.
>>
>>> +}
>>
>> [...]
>>
>>> + /* hwmon_dev points to device hwmon<i> */
>>> + hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat->name,
>>> + ddat,
>>> + &hwmon_chip_info,
>>> + NULL);
>>> + if (IS_ERR(hwmon_dev)) {
>>> + drm_warn(&xe->drm, "Fail to register xe hwmon, Err:%ld\n",
>>> PTR_ERR(hwmon_dev));
>>
>> I think this is better:
>>
>> drm_warn(&xe->drm, "Fail to register xe hwmon (%pe)\n", hwmon_dev);
>>
>>> + xe->hwmon = NULL;
>>> + return;
>>> + }
>>> +
>>> + ddat->hwmon_dev = hwmon_dev;
>>> +}
>>> +
>>> +void xe_hwmon_unregister(struct xe_device *xe)
>>> +{
>>> + xe->hwmon = NULL;
>>
>> I think this is not necessary. Will xe check for hwmon at some
>> point?
>>
>> Andi
>>
>>> +}
>
next prev parent reply other threads:[~2023-08-04 13:19 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-02 13:52 [Intel-xe] [PATCH v3 0/6] Add HWMON support for DGFX Badal Nilawar
2023-08-02 13:52 ` Badal Nilawar
2023-08-02 13:49 ` [Intel-xe] ✓ CI.Patch_applied: success for Add HWMON support for DGFX (rev3) Patchwork
2023-08-02 13:49 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-08-02 13:50 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-08-02 13:52 ` [Intel-xe] [PATCH v3 1/6] drm/xe/hwmon: Add HWMON infrastructure Badal Nilawar
2023-08-02 13:52 ` Badal Nilawar
2023-08-02 14:15 ` [Intel-xe] " Guenter Roeck
2023-08-02 14:15 ` Guenter Roeck
2023-08-02 22:40 ` [Intel-xe] " Andi Shyti
2023-08-02 22:40 ` Andi Shyti
2023-08-02 23:11 ` [Intel-xe] " Guenter Roeck
2023-08-02 23:11 ` Guenter Roeck
2023-08-02 23:34 ` [Intel-xe] " Andi Shyti
2023-08-02 23:34 ` Andi Shyti
2023-08-03 0:06 ` [Intel-xe] " Guenter Roeck
2023-08-03 0:06 ` Guenter Roeck
2023-08-02 23:12 ` [Intel-xe] " Guenter Roeck
2023-08-02 23:12 ` Guenter Roeck
2023-08-04 13:19 ` Nilawar, Badal [this message]
2023-08-04 13:19 ` Nilawar, Badal
2023-08-04 14:26 ` [Intel-xe] " Guenter Roeck
2023-08-04 14:26 ` Guenter Roeck
2023-08-04 14:36 ` [Intel-xe] " Nilawar, Badal
2023-08-04 14:36 ` Nilawar, Badal
2023-08-08 21:31 ` [Intel-xe] " Rodrigo Vivi
2023-08-08 21:31 ` Rodrigo Vivi
2023-08-08 22:07 ` Guenter Roeck
2023-08-08 22:07 ` Guenter Roeck
2023-08-11 16:01 ` Rodrigo Vivi
2023-08-11 16:01 ` Rodrigo Vivi
2023-08-11 17:39 ` Guenter Roeck
2023-08-11 17:39 ` Guenter Roeck
2023-08-11 18:48 ` Rodrigo Vivi
2023-08-11 18:48 ` Rodrigo Vivi
2023-08-04 14:43 ` Nilawar, Badal
2023-08-04 14:43 ` Nilawar, Badal
2023-08-04 13:25 ` [Intel-xe] " Nilawar, Badal
2023-08-04 13:25 ` Nilawar, Badal
2023-08-02 13:52 ` [Intel-xe] [PATCH v3 2/6] drm/xe/hwmon: Expose power attributes Badal Nilawar
2023-08-02 13:52 ` Badal Nilawar
2023-08-02 23:23 ` [Intel-xe] " Andi Shyti
2023-08-02 23:23 ` Andi Shyti
2023-08-04 14:21 ` [Intel-xe] " Nilawar, Badal
2023-08-04 14:21 ` Nilawar, Badal
2023-08-02 13:52 ` [Intel-xe] [PATCH v3 3/6] drm/xe/hwmon: Expose card reactive critical power Badal Nilawar
2023-08-02 13:52 ` Badal Nilawar
2023-08-02 23:28 ` [Intel-xe] " Andi Shyti
2023-08-02 23:28 ` Andi Shyti
2023-08-04 13:31 ` [Intel-xe] " Nilawar, Badal
2023-08-04 13:31 ` Nilawar, Badal
2023-08-02 13:52 ` [Intel-xe] [PATCH v3 4/6] drm/xe/hwmon: Expose input voltage attribute Badal Nilawar
2023-08-02 13:52 ` Badal Nilawar
2023-08-02 23:32 ` [Intel-xe] " Andi Shyti
2023-08-02 23:32 ` Andi Shyti
2023-08-04 13:30 ` [Intel-xe] " Nilawar, Badal
2023-08-04 13:30 ` Nilawar, Badal
2023-08-02 13:52 ` [Intel-xe] [PATCH v3 5/6] drm/xe/hwmon: Expose hwmon energy attribute Badal Nilawar
2023-08-02 13:52 ` Badal Nilawar
2023-08-02 14:14 ` [Intel-xe] " Guenter Roeck
2023-08-02 14:14 ` Guenter Roeck
2023-08-03 6:34 ` [Intel-xe] " Nilawar, Badal
2023-08-03 6:34 ` Nilawar, Badal
2023-08-03 14:42 ` [Intel-xe] " Guenter Roeck
2023-08-03 14:42 ` Guenter Roeck
2023-08-02 13:52 ` [Intel-xe] [PATCH v3 6/6] drm/xe/hwmon: Expose power1_max_interval Badal Nilawar
2023-08-02 13:52 ` Badal Nilawar
2023-08-02 13:54 ` [Intel-xe] ✓ CI.Build: success for Add HWMON support for DGFX (rev3) Patchwork
2023-08-02 13:54 ` [Intel-xe] ✗ CI.Hooks: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=436c15bf-c031-9f72-c4cc-c7ff1600fdbf@intel.com \
--to=badal.nilawar@intel.com \
--cc=andi.shyti@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux@roeck-us.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.