From: a.hajda@samsung.com (Andrzej Hajda) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 4/7] drm/i2c: tda998x: convert to bridge driver Date: Tue, 28 Aug 2018 09:31:53 +0200 [thread overview] Message-ID: <20180828073156eucas1p21e13ba5d7702e6147a05b9750c8eb054~O__x-ibC70308603086eucas1p2B@eucas1p2.samsung.com> (raw) In-Reply-To: <20180827175947.GE30658@n2100.armlinux.org.uk> On 27.08.2018 19:59, Russell King - ARM Linux wrote: > Hi Andrzej, > > On Mon, Aug 27, 2018 at 06:15:59PM +0200, Andrzej Hajda wrote: >> On 30.07.2018 18:42, Russell King wrote: >>> static void tda998x_destroy(struct tda998x_priv *priv) >>> { >>> + drm_bridge_remove(&priv->bridge); >>> + >>> /* disable all IRQs and free the IRQ handler */ >>> cec_write(priv, REG_CEC_RXSHPDINTENA, 0); >>> reg_clear(priv, REG_INT_FLAGS_2, INT_FLAGS_2_EDID_BLK_RD); >>> @@ -1650,6 +1663,7 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv) >>> mutex_init(&priv->mutex); /* protect the page access */ >>> mutex_init(&priv->audio_mutex); /* protect access from audio thread */ >>> mutex_init(&priv->edid_mutex); >>> + INIT_LIST_HEAD(&priv->bridge.list); >> This line can be probably removed, unless there is a reason I am not >> aware of. > The addition above of drm_bridge_remove() to tda998x_destroy() means > that we end up calling this function in the error cleanup path. This > avoids unnecessary complexity with lots of different gotos - tda998x > has had a long history of not cleaning up stuff properly. 1. bridge.list is/should be a private field of drm_bridge framework, so it's direct usage in driver looks like layer violation. 2. Calling drm_bridge_remove() without drm_bridge_add() is not strictly forbidden, but at least looks very suspicious. Even if current implementation tolerates it, it can change in the future. Neither argument is a blocker IMO so if you prefer to stay with current solution please add a comment in the code explaining why do you initializes list field, the code at first sight looks suspicious. > devm interfaces for bridge do not help avoid that - devm stuff only > works if everything that is registered previously is cleaned up via > devm mechanisms to ensure that a device's interface becomes unavailable > before stuff (eg, edid timers, detect work) is started to be cleaned up. > Otherwise, there's a chance of this stuff being triggered during > tear-down. > >>> +static int tda998x_bind(struct device *dev, struct device *master, void *data) >>> +{ >>> + struct i2c_client *client = to_i2c_client(dev); >>> + struct drm_device *drm = data; >>> + struct tda998x_priv *priv; >>> + int ret; >>> + >>> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); >>> + if (!priv) >>> + return -ENOMEM; >>> + >>> + dev_set_drvdata(dev, priv); >>> + >>> + ret = tda998x_create(client, priv); >>> + if (ret) >>> + return ret; >>> + >>> + ret = tda998x_encoder_init(dev, drm); >>> + if (ret) { >>> + tda998x_destroy(priv); >>> + return ret; >>> + } >>> + return 0; >> It could be replaced by: >> ??? ret = tda998x_encoder_init(dev, drm); >> ??? if (ret) >> ??? ??? tda998x_destroy(priv); >> ??? return ret; >> >> but this is probably matter of taste. > It's not clear to me what "It" is - I think you're suggesting combining > tda998x_create() and tda998x_encoder_init() ? No, just simplifying error path. > > The code is structured this way to make the following patches easier - > there is no point of combining things only to have to then break them > apart again in a later patch. Please see patch 7, where tda998x_create() > moves out of this function, where exactly this happens. OK. As I said: up to you. > >> Moreover I guess priv->is_on could be removed if enable/disable >> callbacks are called only by drm_core, but this is for another patch. > Is it guaranteed that a bridge ->enable or ->disable callback won't be > called twice, even for legacy drivers? I think atomic guarantees this > but I don't think it's guaranteed for legacy drivers. > > I'm guessing Rob had a reason why he added the check when he originally > created the driver (encoder ->dpms can be called for the same dpms > state multiple times?) > OK, my guess was incorrect. Regards Andrzej
WARNING: multiple messages have this Message-ID (diff)
From: Andrzej Hajda <a.hajda@samsung.com> To: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: David Airlie <airlied@linux.ie>, Liviu Dudau <Liviu.Dudau@arm.com>, dri-devel@lists.freedesktop.org, Tomi Valkeinen <tomi.valkeinen@ti.com>, Jyri Sarha <jsarha@ti.com>, Peter Rosin <peda@axentia.se>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 4/7] drm/i2c: tda998x: convert to bridge driver Date: Tue, 28 Aug 2018 09:31:53 +0200 [thread overview] Message-ID: <20180828073156eucas1p21e13ba5d7702e6147a05b9750c8eb054~O__x-ibC70308603086eucas1p2B@eucas1p2.samsung.com> (raw) In-Reply-To: <20180827175947.GE30658@n2100.armlinux.org.uk> On 27.08.2018 19:59, Russell King - ARM Linux wrote: > Hi Andrzej, > > On Mon, Aug 27, 2018 at 06:15:59PM +0200, Andrzej Hajda wrote: >> On 30.07.2018 18:42, Russell King wrote: >>> static void tda998x_destroy(struct tda998x_priv *priv) >>> { >>> + drm_bridge_remove(&priv->bridge); >>> + >>> /* disable all IRQs and free the IRQ handler */ >>> cec_write(priv, REG_CEC_RXSHPDINTENA, 0); >>> reg_clear(priv, REG_INT_FLAGS_2, INT_FLAGS_2_EDID_BLK_RD); >>> @@ -1650,6 +1663,7 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv) >>> mutex_init(&priv->mutex); /* protect the page access */ >>> mutex_init(&priv->audio_mutex); /* protect access from audio thread */ >>> mutex_init(&priv->edid_mutex); >>> + INIT_LIST_HEAD(&priv->bridge.list); >> This line can be probably removed, unless there is a reason I am not >> aware of. > The addition above of drm_bridge_remove() to tda998x_destroy() means > that we end up calling this function in the error cleanup path. This > avoids unnecessary complexity with lots of different gotos - tda998x > has had a long history of not cleaning up stuff properly. 1. bridge.list is/should be a private field of drm_bridge framework, so it's direct usage in driver looks like layer violation. 2. Calling drm_bridge_remove() without drm_bridge_add() is not strictly forbidden, but at least looks very suspicious. Even if current implementation tolerates it, it can change in the future. Neither argument is a blocker IMO so if you prefer to stay with current solution please add a comment in the code explaining why do you initializes list field, the code at first sight looks suspicious. > devm interfaces for bridge do not help avoid that - devm stuff only > works if everything that is registered previously is cleaned up via > devm mechanisms to ensure that a device's interface becomes unavailable > before stuff (eg, edid timers, detect work) is started to be cleaned up. > Otherwise, there's a chance of this stuff being triggered during > tear-down. > >>> +static int tda998x_bind(struct device *dev, struct device *master, void *data) >>> +{ >>> + struct i2c_client *client = to_i2c_client(dev); >>> + struct drm_device *drm = data; >>> + struct tda998x_priv *priv; >>> + int ret; >>> + >>> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); >>> + if (!priv) >>> + return -ENOMEM; >>> + >>> + dev_set_drvdata(dev, priv); >>> + >>> + ret = tda998x_create(client, priv); >>> + if (ret) >>> + return ret; >>> + >>> + ret = tda998x_encoder_init(dev, drm); >>> + if (ret) { >>> + tda998x_destroy(priv); >>> + return ret; >>> + } >>> + return 0; >> It could be replaced by: >> ret = tda998x_encoder_init(dev, drm); >> if (ret) >> tda998x_destroy(priv); >> return ret; >> >> but this is probably matter of taste. > It's not clear to me what "It" is - I think you're suggesting combining > tda998x_create() and tda998x_encoder_init() ? No, just simplifying error path. > > The code is structured this way to make the following patches easier - > there is no point of combining things only to have to then break them > apart again in a later patch. Please see patch 7, where tda998x_create() > moves out of this function, where exactly this happens. OK. As I said: up to you. > >> Moreover I guess priv->is_on could be removed if enable/disable >> callbacks are called only by drm_core, but this is for another patch. > Is it guaranteed that a bridge ->enable or ->disable callback won't be > called twice, even for legacy drivers? I think atomic guarantees this > but I don't think it's guaranteed for legacy drivers. > > I'm guessing Rob had a reason why he added the check when he originally > created the driver (encoder ->dpms can be called for the same dpms > state multiple times?) > OK, my guess was incorrect. Regards Andrzej _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-08-28 7:31 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-07-30 16:41 [PATCH v2 0/7] tda998x: allow use with bridge based devices Russell King - ARM Linux 2018-07-30 16:41 ` Russell King - ARM Linux 2018-07-30 16:42 ` [PATCH v2 1/7] drm/i2c: tda998x: find the drm_device via the drm_connector Russell King 2018-07-30 16:42 ` Russell King 2018-07-30 16:42 ` [PATCH v2 2/7] drm/i2c: tda998x: split tda998x_encoder_dpms into enable/disable Russell King 2018-07-30 16:42 ` Russell King 2018-07-31 5:46 ` Peter Rosin 2018-07-31 5:46 ` Peter Rosin 2018-07-30 16:42 ` [PATCH v2 3/7] drm/i2c: tda998x: move tda998x_set_config() into tda998x_create() Russell King 2018-07-30 16:42 ` Russell King 2018-07-30 16:42 ` [PATCH v2 4/7] drm/i2c: tda998x: convert to bridge driver Russell King 2018-07-30 16:42 ` Russell King 2018-07-31 7:37 ` Peter Rosin 2018-07-31 7:37 ` Peter Rosin 2018-08-08 19:09 ` Sean Paul 2018-08-08 19:09 ` Sean Paul 2018-08-08 22:15 ` Russell King - ARM Linux 2018-08-08 22:15 ` Russell King - ARM Linux 2018-08-10 16:11 ` Sean Paul 2018-08-10 16:11 ` Sean Paul 2018-08-10 16:50 ` Russell King - ARM Linux 2018-08-10 16:50 ` Russell King - ARM Linux 2018-08-10 17:02 ` Sean Paul 2018-08-10 17:02 ` Sean Paul 2018-08-10 17:16 ` Russell King - ARM Linux 2018-08-10 17:16 ` Russell King - ARM Linux 2018-08-14 10:42 ` Daniel Vetter 2018-08-14 10:42 ` Daniel Vetter 2018-08-14 10:48 ` Russell King - ARM Linux 2018-08-14 10:48 ` Russell King - ARM Linux 2018-08-14 11:11 ` Daniel Vetter 2018-08-14 11:11 ` Daniel Vetter 2018-08-27 16:15 ` Andrzej Hajda 2018-08-27 16:15 ` Andrzej Hajda 2018-08-27 17:59 ` Russell King - ARM Linux 2018-08-27 17:59 ` Russell King - ARM Linux 2018-08-28 7:31 ` Andrzej Hajda [this message] 2018-08-28 7:31 ` Andrzej Hajda 2018-07-30 16:42 ` [PATCH v2 5/7] drm/i2c: tda998x: allocate tda998x_priv inside tda998x_create() Russell King 2018-07-30 16:42 ` Russell King 2018-07-30 16:42 ` [PATCH v2 6/7] drm/i2c: tda998x: cleanup from previous changes Russell King 2018-07-30 16:42 ` Russell King 2018-07-30 16:42 ` [PATCH v2 7/7] drm/i2c: tda998x: register bridge outside of component helper Russell King 2018-07-30 16:42 ` Russell King 2018-08-27 16:19 ` Andrzej Hajda 2018-08-27 16:19 ` Andrzej Hajda 2018-07-31 5:44 ` [PATCH v2 0/7] tda998x: allow use with bridge based devices Peter Rosin 2018-07-31 5:44 ` Peter Rosin 2018-07-31 7:41 ` Russell King - ARM Linux 2018-07-31 7:41 ` Russell King - ARM Linux 2018-07-31 7:53 ` Peter Rosin 2018-07-31 7:53 ` Peter Rosin 2018-07-31 9:23 ` Russell King - ARM Linux 2018-07-31 9:23 ` Russell King - ARM Linux 2018-07-31 9:26 ` [PATCH 1/4] drm/i2c: tda998x: move mode_valid() to bridge Russell King 2018-07-31 9:26 ` Russell King 2018-08-27 16:24 ` Andrzej Hajda 2018-08-27 16:24 ` Andrzej Hajda 2018-07-31 9:26 ` [PATCH 2/4] drm/i2c: tda998x: get rid of private fill_modes function Russell King 2018-07-31 9:26 ` Russell King 2018-07-31 9:26 ` [PATCH 3/4] drm/i2c: tda998x: correct PLL divider calculation Russell King 2018-07-31 9:26 ` Russell King 2018-07-31 9:26 ` [PATCH 4/4] drm/i2c: tda998x: add support for pixel repeated modes Russell King 2018-07-31 9:26 ` Russell King 2018-07-31 9:42 ` Russell King - ARM Linux 2018-07-31 9:42 ` Russell King - ARM Linux 2018-07-31 10:43 ` [PATCH v2 0/7] tda998x: allow use with bridge based devices Peter Rosin 2018-07-31 10:43 ` Peter Rosin 2018-07-31 11:15 ` Russell King - ARM Linux 2018-07-31 11:15 ` Russell King - ARM Linux 2018-08-01 9:01 ` Peter Rosin 2018-08-01 9:01 ` Peter Rosin 2018-08-01 9:35 ` Russell King - ARM Linux 2018-08-01 9:35 ` Russell King - ARM Linux 2018-08-02 6:06 ` Peter Rosin 2018-08-02 6:06 ` Peter Rosin 2018-11-12 16:50 ` Peter Rosin 2018-11-12 16:50 ` Peter Rosin 2018-11-12 17:00 ` Russell King - ARM Linux 2018-11-12 17:00 ` Russell King - ARM Linux
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='20180828073156eucas1p21e13ba5d7702e6147a05b9750c8eb054~O__x-ibC70308603086eucas1p2B@eucas1p2.samsung.com' \ --to=a.hajda@samsung.com \ --cc=linux-arm-kernel@lists.infradead.org \ /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: linkBe 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.