>-----Original Message----- >From: Nikula, Jani >Sent: Wednesday, April 8, 2015 1:34 PM >To: R, Durgadoss; intel-gfx@xxxxxxxxxxxxxxxxxxxxx >Cc: R, Durgadoss >Subject: Re: [PATCH] drm/i915: Add debugfs to read any DPCD register > >On Wed, 08 Apr 2015, Durgadoss R <durgadoss.r@xxxxxxxxx> wrote: >> This patch creates a connector specific debugfs >> interface to read any particular DPCD register. >> The DPCD register address (hex format) is written >> to 'i915_dpcd_addr' interface and the corresponding >> value can be read from 'i915_dpcd_val' interface. >> >> Example usage: >> echo 0x70 > i915_dpcd_addr >> cat i915_dpcd_val >> DPCD[0x70]:0x1 > >I am still not overjoyed about the interface (because it has a state), >but I don't have anything better to suggest either. I'll defer to others >to make the taste judgement... > >Review comments for the implementation inline. > >BR, >Jani. > > >> >> Signed-off-by: Durgadoss R <durgadoss.r@xxxxxxxxx> >> --- >> This patch is based on top of Jani's patch: >> "add i915 specific connector debugfs file for DPCD" >> [https://freedesktop.org/patch/43332/] > >Already committed. > >> >> drivers/gpu/drm/i915/i915_debugfs.c | 102 +++++++++++++++++++++++++++++++++++- >> drivers/gpu/drm/i915/intel_drv.h | 1 + >> 2 files changed, 102 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c >> index 10ca511..9951d84 100644 >> --- a/drivers/gpu/drm/i915/i915_debugfs.c >> +++ b/drivers/gpu/drm/i915/i915_debugfs.c >> @@ -4865,6 +4865,101 @@ static const struct file_operations i915_dpcd_fops = { >> .release = single_release, >> }; >> >> +static ssize_t i915_dpcd_addr_write(struct file *file, const char __user *ubuf, >> + size_t len, loff_t *offp) >> +{ >> + struct seq_file *m = file->private_data; >> + struct drm_connector *connector = m->private; >> + struct intel_dp *intel_dp = >> + enc_to_intel_dp(&intel_attached_encoder(connector)->base); >> + unsigned int reg_addr; >> + char tmp[16]; >> + int ret; >> + >> + if (!intel_dp) >> + return -EINVAL; > >I think it's highly unlikely this will be NULL. You're more likely to >oops above if something went wrong (see enc_to_intel_dp and >intel_attached_encoder). Also, -ENODEV? Ok.. Will remove this check in next version.. > >> + >> + if (len >= sizeof(tmp)) >> + return -EINVAL; >> + >> + if (copy_from_user(tmp, ubuf, len)) >> + return -EFAULT; >> + >> + tmp[len] = '\0'; >> + >> + ret = sscanf(tmp, "%x\n", ®_addr); > >See kstrtouint. > >> + if (ret == 0) >> + return -EINVAL; >> + >> + intel_dp->debugfs_dpcd_addr = reg_addr; >> + >> + return len; >> +} >> + >> +static int i915_dpcd_addr_show(struct seq_file *m, void *data) >> +{ >> + struct drm_connector *connector = m->private; >> + struct intel_dp *intel_dp = >> + enc_to_intel_dp(&intel_attached_encoder(connector)->base); >> + >> + if (!intel_dp) >> + return -EINVAL; > >Same as above. > >> + >> + seq_printf(m, "0x%x\n", intel_dp->debugfs_dpcd_addr); >> + >> + return 0; >> +} >> + >> +static int i915_dpcd_addr_open(struct inode *inode, struct file *file) >> +{ >> + return single_open(file, i915_dpcd_addr_show, inode->i_private); >> +} >> + >> +static const struct file_operations i915_dpcd_addr_fops = { >> + .owner = THIS_MODULE, >> + .open = i915_dpcd_addr_open, >> + .read = seq_read, >> + .write = i915_dpcd_addr_write, >> + .llseek = seq_lseek, >> + .release = single_release, >> +}; >> + >> +static int i915_dpcd_val_show(struct seq_file *m, void *data) >> +{ >> + struct drm_connector *connector = m->private; >> + struct intel_dp *intel_dp = >> + enc_to_intel_dp(&intel_attached_encoder(connector)->base); >> + unsigned int addr; >> + u8 buf[1]; > >Might be more obvious to just have u8 val, and use a pointer to >it. *shrug*. > >> + int ret; >> + >> + if (!intel_dp) >> + return -EINVAL; > >Same as above. > >> + >> + addr = intel_dp->debugfs_dpcd_addr; >> + ret = drm_dp_dpcd_readb(&intel_dp->aux, addr, buf); >> + if (ret < 0) { >> + DRM_ERROR("dpcd read for 0x%x failed:%d\n", addr, ret); > >I think there'll already be errors in the log at this point. This is >probably redundant. > >> + return ret; >> + } >> + >> + seq_printf(m, "DPCD[0x%x]:0x%x\n", addr, buf[0]); > >For an interface better suited for tools than humans, I'd drop all the >fluff and just print the content. Maybe use 0x%02x for format. I added this because we don't have locking constructs for our state. For tools, yes, I agree that just a value would do.. Thanks, Durga > >> + return 0; >> +} >> + >> +static int i915_dpcd_val_open(struct inode *inode, struct file *file) >> +{ >> + return single_open(file, i915_dpcd_val_show, inode->i_private); >> +} >> + >> +static const struct file_operations i915_dpcd_val_fops = { >> + .owner = THIS_MODULE, >> + .open = i915_dpcd_val_open, >> + .read = seq_read, >> + .llseek = seq_lseek, >> + .release = single_release, >> +}; >> + >> /** >> * i915_debugfs_connector_add - add i915 specific connector debugfs files >> * @connector: pointer to a registered drm_connector >> @@ -4883,9 +4978,14 @@ int i915_debugfs_connector_add(struct drm_connector *connector) >> return -ENODEV; >> >> if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort || >> - connector->connector_type == DRM_MODE_CONNECTOR_eDP) >> + connector->connector_type == DRM_MODE_CONNECTOR_eDP) { >> debugfs_create_file("i915_dpcd", S_IRUGO, root, connector, >> &i915_dpcd_fops); >> + debugfs_create_file("i915_dpcd_addr", S_IRUGO | S_IWUSR, >> + root, connector, &i915_dpcd_addr_fops); >> + debugfs_create_file("i915_dpcd_val", S_IRUGO, root, >> + connector, &i915_dpcd_val_fops); >> + } >> >> return 0; >> } >> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h >> index 4799b11..0594baa 100644 >> --- a/drivers/gpu/drm/i915/intel_drv.h >> +++ b/drivers/gpu/drm/i915/intel_drv.h >> @@ -642,6 +642,7 @@ struct intel_dp { >> unsigned long last_power_cycle; >> unsigned long last_power_on; >> unsigned long last_backlight_off; >> + unsigned int debugfs_dpcd_addr; >> >> struct notifier_block edp_notifier; >> >> -- >> 1.9.1 >> > >-- >Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
