[PATCH v5 1/4] drm/bridge: add support for sn65dsi86 bridge driver
spanda at codeaurora.org
spanda at codeaurora.org
Fri May 11 11:16:11 UTC 2018
On 2018-05-08 03:50, Stephen Boyd wrote:
> Quoting Sean Paul (2018-05-02 12:03:16)
>> On Wed, May 02, 2018 at 10:01:59AM +0530, Sandeep Panda wrote:
>>
>> > + struct drm_display_mode curr_mode;
>> > + struct mutex lock;
>> > + unsigned int ctrl_ref_count;
>> > +};
>> > +
>> > +static const struct regmap_range ti_sn_bridge_volatile_ranges[] = {
>> > + { .range_min = 0, .range_max = 0xff },
>> > +};
>> > +
>> > +static const struct regmap_access_table ti_sn_bridge_volatile_table = {
>> > + .yes_ranges = ti_sn_bridge_volatile_ranges,
>> > + .n_yes_ranges = ARRAY_SIZE(ti_sn_bridge_volatile_ranges),
>> > +};
>> > +
>> > +static const struct regmap_config ti_sn_bridge_regmap_config = {
>> > + .reg_bits = 8,
>> > + .val_bits = 8,
>> > + .volatile_table = &ti_sn_bridge_volatile_table,
>> > + .cache_type = REGCACHE_NONE,
>> > +};
>> > +
>> > +static int ti_sn_bridge_power_ctrl(struct ti_sn_bridge *pdata, bool enable)
>> > +{
>> > + int ret = 0;
>> > +
>> > + mutex_lock(&pdata->lock);
>> > + if (enable)
>> > + pdata->ctrl_ref_count++;
>> > + else
>> > + pdata->ctrl_ref_count--;
>>
>> I think you should use a kref instead of rolling your own ref_count.
>> You can
>> handle release by calling kref_put_mutex(), which will handle the
>> reference and
>> the lock. On the acquire side, you can use kref_get_unless_zero which
>> will be
>> fast if the reference is already active.
>
> Why not use runtime PM?
I think PM runtime will be a better approach since we are trying to
protect bridge power source related resources here.
More information about the dri-devel
mailing list