| Message ID | d6381c020ea1c848a7044d830bdb0ec9663d1619.1561735433.git.andrzej.p@collabora.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Associate ddc adapters with connectors | expand |
Hi
I like the idea, but would prefer a more structured approach.
Setting connector->ddc before calling drm_sysfs_connector_add() seems
error prone. The dependency is not really clear from the code or interfaces.
The other thing is that drivers I mostly work on, ast and mgag200, have
code like this:
struct ast_i2c_chan {
struct i2c_adapter adapter;
struct drm_device *dev;
struct i2c_algo_bit_data bit;
};
struct ast_connector {
struct drm_connector base;
struct ast_i2c_chan *i2c;
};
It already encodes the connection between connector and ddc adapter.
I suggest to introduce struct drm_i2c_adapter
struct drm_i2c_adapter {
struct i2c_adapter base;
struct drm_connector *connector;
};
and convert drivers over to it. Ast would look like this:
struct ast_i2c_chan {
struct drm_i2c_adapter adapter;
struct i2c_algo_bit_data bit;
};
Two new sysfs functions would set up and remove the file.
int drm_sysfs_i2c_adapter_add(struct drm_i2c_adapter *i2c);
void drm_sysfs_i2c_adapter_remove(struct drm_i2c_adapter *i2c);
The i2c adapter, connector->ddc pointer and sysfs entry would be
initialized by
drm_i2c_adapter_init(struct drm_i2c_adapter *i2c, struct connector
*connector, void *algo_data);
and cleaned up by
drm_i2c_adapter_remove(struct drm_i2c_adapter *i2c);
Thoughts?
Best regards
Thomas
Am 28.06.19 um 18:01 schrieb Andrzej Pietrasiewicz:
> Add generic code which creates symbolic links in sysfs, pointing to ddc
> interface used by a particular video output. For example:
>
> ls -l /sys/class/drm/card0-HDMI-A-1/ddc
> lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \
> -> ../../../../soc/13880000.i2c/i2c-2
>
> This makes it easy for user to associate a display with its ddc adapter
> and use e.g. ddcutil to control the chosen monitor.
>
> This patch adds an i2c_adapter pointer to struct drm_connector. Particular
> drivers can then use it instead of using their own private instance. If a
> connector contains a ddc, then create a symbolic link in sysfs.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/drm_sysfs.c | 7 +++++++
> include/drm/drm_connector.h | 11 +++++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index ad10810bc972..26d359b39785 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -294,6 +294,9 @@ int drm_sysfs_connector_add(struct drm_connector *connector)
> /* Let userspace know we have a new connector */
> drm_sysfs_hotplug_event(dev);
>
> + if (connector->ddc)
> + return sysfs_create_link(&connector->kdev->kobj,
> + &connector->ddc->dev.kobj, "ddc");
> return 0;
> }
>
> @@ -301,6 +304,10 @@ void drm_sysfs_connector_remove(struct drm_connector *connector)
> {
> if (!connector->kdev)
> return;
> +
> + if (connector->ddc)
> + sysfs_remove_link(&connector->kdev->kobj, "ddc");
> +
> DRM_DEBUG("removing \"%s\" from sysfs\n",
> connector->name);
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index ca745d9feaf5..1ad3d1d54ba7 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -23,6 +23,7 @@
> #ifndef __DRM_CONNECTOR_H__
> #define __DRM_CONNECTOR_H__
>
> +#include <linux/i2c.h>
> #include <linux/list.h>
> #include <linux/llist.h>
> #include <linux/ctype.h>
> @@ -1308,6 +1309,16 @@ struct drm_connector {
> * [0]: progressive, [1]: interlaced
> */
> int audio_latency[2];
> +
> + /**
> + * @ddc: associated ddc adapter.
> + * A connector usually has its associated ddc adapter. If a driver uses
> + * this field, then an appropriate symbolic link is created in connector
> + * sysfs directory to make it easy for the user to tell which i2c
> + * adapter is for a particular display.
> + */
> + struct i2c_adapter *ddc;
> +
> /**
> * @null_edid_counter: track sinks that give us all zeros for the EDID.
> * Needed to workaround some HW bugs where we get all 0s
>
Hi Thomas, Thank you for your comments. Please see inline. W dniu 30.06.2019 o 10:12, Thomas Zimmermann pisze: > Hi > > I like the idea, but would prefer a more structured approach. > > Setting connector->ddc before calling drm_sysfs_connector_add() seems > error prone. The dependency is not really clear from the code or interfaces. > > The other thing is that drivers I mostly work on, ast and mgag200, have > code like this: > > struct ast_i2c_chan { > struct i2c_adapter adapter; > struct drm_device *dev; > struct i2c_algo_bit_data bit; > }; > > struct ast_connector { > struct drm_connector base; > struct ast_i2c_chan *i2c; > }; > > It already encodes the connection between connector and ddc adapter. > > I suggest to introduce struct drm_i2c_adapter > > struct drm_i2c_adapter { > struct i2c_adapter base; > struct drm_connector *connector; > }; > > and convert drivers over to it. Ast would look like this: > > struct ast_i2c_chan { > struct drm_i2c_adapter adapter; > struct i2c_algo_bit_data bit; > }; > There are few flavors of these drivers. In some of them the i2c_adapter for ddc is allocated and initialized by the driver, which must provide a place in memory to hold the adapter. ast is an example of this approach. But there are others, such as for example exynos_hdmi.c. It gets its ddc adapter with of_find_i2c_adapter_by_node() and merely stores a pointer to it, while not managing the memory needed to hold the i2c_adapter. Do you have any idea how to accommodate these various flavors of drivers in the scheme you propose? Andrzej
Hi Am 01.07.19 um 15:27 schrieb Andrzej Pietrasiewicz: > Hi Thomas, > > Thank you for your comments. Please see inline. > > W dniu 30.06.2019 o 10:12, Thomas Zimmermann pisze: >> Hi >> >> I like the idea, but would prefer a more structured approach. >> >> Setting connector->ddc before calling drm_sysfs_connector_add() seems >> error prone. The dependency is not really clear from the code or >> interfaces. >> >> The other thing is that drivers I mostly work on, ast and mgag200, have >> code like this: >> >> struct ast_i2c_chan { >> struct i2c_adapter adapter; >> struct drm_device *dev; >> struct i2c_algo_bit_data bit; >> }; >> >> struct ast_connector { >> struct drm_connector base; >> struct ast_i2c_chan *i2c; >> }; >> >> It already encodes the connection between connector and ddc adapter. >> >> I suggest to introduce struct drm_i2c_adapter >> >> struct drm_i2c_adapter { >> struct i2c_adapter base; >> struct drm_connector *connector; >> }; >> >> and convert drivers over to it. Ast would look like this: >> >> struct ast_i2c_chan { >> struct drm_i2c_adapter adapter; >> struct i2c_algo_bit_data bit; >> }; >> > > There are few flavors of these drivers. In some of them > the i2c_adapter for ddc is allocated and initialized by > the driver, which must provide a place in memory to hold > the adapter. ast is an example of this approach. > > But there are others, such as for example exynos_hdmi.c. > It gets its ddc adapter with of_find_i2c_adapter_by_node() > and merely stores a pointer to it, while not managing the > memory needed to hold the i2c_adapter. I see. > Do you have any idea how to accommodate these various > flavors of drivers in the scheme you propose? Something like struct drm_i2c_adapter { struct i2c_adapter *adapter; struct drm_connector *connector; }; with adapter either being allocated dynamically or acquired via of_find_i2c_adapter_by_node(); with separate init and finish functions for each variant. But it looks like over-abstraction to me. Without prototyping the idea, I cannot say if it's worth the effort. For something more simple, maybe just have a function to attach an i2c adapter to a connector: drm_connector_attach_i2c_adapter(connector, i2c_adapter) which sets the connector's ddc pointer and creates the sysfs entry if the connector's entry is already present. Best regards Thomas > Andrzej > >
On 01.07.2019 16:41, Thomas Zimmermann wrote: > Hi > > Am 01.07.19 um 15:27 schrieb Andrzej Pietrasiewicz: >> Hi Thomas, >> >> Thank you for your comments. Please see inline. >> >> W dniu 30.06.2019 o 10:12, Thomas Zimmermann pisze: >>> Hi >>> >>> I like the idea, but would prefer a more structured approach. >>> >>> Setting connector->ddc before calling drm_sysfs_connector_add() seems >>> error prone. The dependency is not really clear from the code or >>> interfaces. >>> >>> The other thing is that drivers I mostly work on, ast and mgag200, have >>> code like this: >>> >>> struct ast_i2c_chan { >>> struct i2c_adapter adapter; >>> struct drm_device *dev; >>> struct i2c_algo_bit_data bit; >>> }; >>> >>> struct ast_connector { >>> struct drm_connector base; >>> struct ast_i2c_chan *i2c; >>> }; >>> >>> It already encodes the connection between connector and ddc adapter. >>> >>> I suggest to introduce struct drm_i2c_adapter >>> >>> struct drm_i2c_adapter { >>> struct i2c_adapter base; >>> struct drm_connector *connector; >>> }; >>> >>> and convert drivers over to it. Ast would look like this: >>> >>> struct ast_i2c_chan { >>> struct drm_i2c_adapter adapter; >>> struct i2c_algo_bit_data bit; >>> }; >>> >> There are few flavors of these drivers. In some of them >> the i2c_adapter for ddc is allocated and initialized by >> the driver, which must provide a place in memory to hold >> the adapter. ast is an example of this approach. >> >> But there are others, such as for example exynos_hdmi.c. >> It gets its ddc adapter with of_find_i2c_adapter_by_node() >> and merely stores a pointer to it, while not managing the >> memory needed to hold the i2c_adapter. > I see. > >> Do you have any idea how to accommodate these various >> flavors of drivers in the scheme you propose? > Something like > > struct drm_i2c_adapter { > struct i2c_adapter *adapter; > struct drm_connector *connector; > }; > > with adapter either being allocated dynamically or acquired via > of_find_i2c_adapter_by_node(); with separate init and finish functions > for each variant. But it looks like over-abstraction to me. Without > prototyping the idea, I cannot say if it's worth the effort. > > For something more simple, maybe just have a function to attach an i2c > adapter to a connector: > > drm_connector_attach_i2c_adapter(connector, i2c_adapter) > > which sets the connector's ddc pointer and creates the sysfs entry if > the connector's entry is already present. I am not sure if such function is really necessary. Assigning ddc field before connector registration seems to be much simpler and quite standard - many fields are initialized this way. Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> -- Regards Andrzej > Best regards > Thomas > >> Andrzej >> >>
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c index ad10810bc972..26d359b39785 100644 --- a/drivers/gpu/drm/drm_sysfs.c +++ b/drivers/gpu/drm/drm_sysfs.c @@ -294,6 +294,9 @@ int drm_sysfs_connector_add(struct drm_connector *connector) /* Let userspace know we have a new connector */ drm_sysfs_hotplug_event(dev); + if (connector->ddc) + return sysfs_create_link(&connector->kdev->kobj, + &connector->ddc->dev.kobj, "ddc"); return 0; } @@ -301,6 +304,10 @@ void drm_sysfs_connector_remove(struct drm_connector *connector) { if (!connector->kdev) return; + + if (connector->ddc) + sysfs_remove_link(&connector->kdev->kobj, "ddc"); + DRM_DEBUG("removing \"%s\" from sysfs\n", connector->name); diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index ca745d9feaf5..1ad3d1d54ba7 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -23,6 +23,7 @@ #ifndef __DRM_CONNECTOR_H__ #define __DRM_CONNECTOR_H__ +#include <linux/i2c.h> #include <linux/list.h> #include <linux/llist.h> #include <linux/ctype.h> @@ -1308,6 +1309,16 @@ struct drm_connector { * [0]: progressive, [1]: interlaced */ int audio_latency[2]; + + /** + * @ddc: associated ddc adapter. + * A connector usually has its associated ddc adapter. If a driver uses + * this field, then an appropriate symbolic link is created in connector + * sysfs directory to make it easy for the user to tell which i2c + * adapter is for a particular display. + */ + struct i2c_adapter *ddc; + /** * @null_edid_counter: track sinks that give us all zeros for the EDID. * Needed to workaround some HW bugs where we get all 0s