From: Sui Jingfeng <suijingfeng@loongson.cn>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/8] drm/loongson: Allow attach drm bridge driver by calling lsdc_output_init()
Date: Mon, 30 Oct 2023 12:13:34 +0800 [thread overview]
Message-ID: <ea335f64-16cc-47aa-b523-0aae6f64e223@loongson.cn> (raw)
In-Reply-To: <CAA8EJpoWXtmMt9vpG9Q4dpv6HnMjtdmEo6rbBszXNG30NhbB1A@mail.gmail.com>
Hi,
On 2023/10/30 07:10, Dmitry Baryshkov wrote:
>> +
>> +/* Built-in HDMI encoder funcs on display pipe 0 */
>> +
>> +static void lsdc_pipe0_hdmi_encoder_reset(struct drm_encoder *encoder)
>> +{
>> + struct drm_device *ddev = encoder->dev;
>> + struct lsdc_device *ldev = to_lsdc(ddev);
>> + u32 val;
>> +
>> + val = PHY_CLOCK_POL | PHY_CLOCK_EN | PHY_DATA_EN;
>> + lsdc_wreg32(ldev, LSDC_CRTC0_DVO_CONF_REG, val);
>> +
>> + /* Using built-in GPIO emulated I2C instead of the hardware I2C */
>> + lsdc_ureg32_clr(ldev, LSDC_HDMI0_INTF_CTRL_REG, HW_I2C_EN);
>> +
>> + /* Help the HDMI phy get out of reset state */
>> + lsdc_wreg32(ldev, LSDC_HDMI0_PHY_CTRL_REG, HDMI_PHY_RESET_N);
>> +
>> + drm_dbg(ddev, "%s reset\n", encoder->name);
>> +
>> + mdelay(20);
>> +}
>> +
>> +const struct drm_encoder_funcs lsdc_pipe0_hdmi_encoder_funcs = {
>> + .reset = lsdc_pipe0_hdmi_encoder_reset,
>> + .destroy = drm_encoder_cleanup,
>> +};
>> +
>> +/* Built-in HDMI encoder funcs on display pipe 1 */
> All pipe 1 code looks like a pipe0, just the registers were changed.
> Could you please refactor that to use a single instance of all
> functions and pass pipe id through the data struct?
> Then you can use macros to determine whether to use pipe 0 or pipe 1 register.
>
Yes, you are right. But please allow me to explain something.
In the past, Thomas told me to untangle it, despite this idea lead to duplicated code(or pattern).
but at the long run, this pay off.
Because the method of passing pipe id will introduce the "if and else" side effects.
But my functions have no if and else.
```
if (pipe == 0) {
...
} else if (pipe == 1) {
...
}
```
Using the C program language's Macro(#define XXX) to generate code is not fun to me.
Because every time you want to change it, It needs my brains to thinking it twice. Maybe
more than twice.
1) It needs my brains to replace the macros manually each time I saw the code.
2) When I want to change(alter) the prototype, I need to worry about all of the instances.
sometimes it is not symmetry. The DVO port and HDMI phy itself is symmetry, but the
external display bridge connected with them are not symmetry. So, there are some registers
located at the domain of this display controller side should change according to the
different type of external display bridge.
3) Code duplication is actually less harmful than unmaintainable.
macros are abstract, as noob level programmer, we completely drop the idea of abstract.
Bad abstract means design failure, this is what we are most afraid of.
Generally, we would like divide the whole into small cases, handle them one by one.
It is actually to review and understand.
4) From the viewpoint of the hardware, the display output hardware suffer from changes.
Because users always want *new* display interface. The need of the users are also varies.
Personally, I think macros are best for the symmetry case, while the output part of a
display pipe always suffer from change.
>> +
>> +static void lsdc_pipe1_hdmi_encoder_reset(struct drm_encoder *encoder)
>> +{
>> + struct drm_device *ddev = encoder->dev;
>> + struct lsdc_device *ldev = to_lsdc(ddev);
>> + u32 val;
>> +
>> + val = PHY_CLOCK_POL | PHY_CLOCK_EN | PHY_DATA_EN;
>> + lsdc_wreg32(ldev, LSDC_CRTC1_DVO_CONF_REG, val);
>> +
>> + /* Using built-in GPIO emulated I2C instead of the hardware I2C */
>> + lsdc_ureg32_clr(ldev, LSDC_HDMI1_INTF_CTRL_REG, HW_I2C_EN);
>> +
>> + /* Help the HDMI phy get out of reset state */
>> + lsdc_wreg32(ldev, LSDC_HDMI1_PHY_CTRL_REG, HDMI_PHY_RESET_N);
>> +
>> + drm_dbg(ddev, "%s reset\n", encoder->name);
>> +
>> + mdelay(20);
>> +}
>> +
>> +const struct drm_encoder_funcs lsdc_pipe1_hdmi_encoder_funcs = {
>> + .reset = lsdc_pipe1_hdmi_encoder_reset,
>> + .destroy = drm_encoder_cleanup,
>> +};
next prev parent reply other threads:[~2023-10-30 4:13 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-29 19:45 [PATCH 0/8] drm/loongson: Submit a mini VBIOS support and a display bridge driver Sui Jingfeng
2023-10-29 19:46 ` [PATCH 1/8] drm/loongson: Introduce a minimal support for Loongson VBIOS Sui Jingfeng
2023-10-29 22:59 ` Dmitry Baryshkov
2023-10-30 3:20 ` Sui Jingfeng
2023-10-29 19:46 ` [PATCH 2/8] drm/loongson: Introduce a drm bridge driver for it66121 HDMI transmitter Sui Jingfeng
2023-10-29 22:53 ` Dmitry Baryshkov
2023-10-30 9:42 ` Sui Jingfeng
2023-10-30 10:01 ` Dmitry Baryshkov
2023-10-30 13:25 ` Sui Jingfeng
2023-10-30 13:39 ` Maxime Ripard
2023-10-30 14:39 ` Sui Jingfeng
2023-10-30 14:56 ` Maxime Ripard
2023-10-30 13:48 ` Dmitry Baryshkov
2023-10-30 14:25 ` Sui Jingfeng
2023-10-30 10:13 ` Maxime Ripard
2023-10-29 19:46 ` [PATCH 3/8] drm/loongson: Allow attach drm bridge driver by calling lsdc_output_init() Sui Jingfeng
2023-10-29 23:10 ` Dmitry Baryshkov
2023-10-30 4:13 ` Sui Jingfeng [this message]
2023-10-30 8:54 ` Sui Jingfeng
2023-10-30 9:16 ` Dmitry Baryshkov
2023-10-30 9:13 ` Sui Jingfeng
2023-10-30 0:12 ` kernel test robot
2023-11-01 2:42 ` kernel test robot
2023-11-04 7:41 ` kernel test robot
2023-11-05 17:27 ` kernel test robot
2023-10-29 19:46 ` [PATCH 4/8] drm/loongson: Started to attach display bridge driver for LS7A1000 Sui Jingfeng
2023-10-29 23:14 ` Dmitry Baryshkov
2023-10-29 19:46 ` [PATCH 5/8] drm/loongson: Using vbios for the LS7A2000 output initialization Sui Jingfeng
2023-10-30 2:28 ` kernel test robot
2023-11-06 17:46 ` kernel test robot
2023-10-29 19:46 ` [PATCH 6/8] drm/loongson: Clean up the output part of LS7A2000 Sui Jingfeng
2023-10-29 23:17 ` Dmitry Baryshkov
2023-10-29 19:46 ` [PATCH 7/8] drm/loongson: Support to infer DC reversion from CPU's PRID value Sui Jingfeng
2023-10-29 23:19 ` Dmitry Baryshkov
2023-10-30 8:50 ` Sui Jingfeng
2023-10-29 19:46 ` [PATCH 8/8] drm/loongson: Add support for the display subsystem in LS2K2000 Sui Jingfeng
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=ea335f64-16cc-47aa-b523-0aae6f64e223@loongson.cn \
--to=suijingfeng@loongson.cn \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mripard@kernel.org \
--cc=tzimmermann@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®