From: Archit Taneja <architt@codeaurora.org>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, Pawel Moll <pawel.moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Andrey Gusakov <andrey.gusakov@cogentembedded.com>,
dri-devel@lists.freedesktop.org, Rob Herring <robh+dt@kernel.org>,
Chris Healy <Chris.Healy@zii.aero>,
Kumar Gala <galak@codeaurora.org>,
Thierry Reding <treding@nvidia.com>
Subject: Re: [PATCH 2/2] drm/bridge: tc358767: Add DPI to eDP bridge driver
Date: Mon, 11 Jul 2016 14:02:19 +0530 [thread overview]
Message-ID: <57835993.4020709@codeaurora.org> (raw)
In-Reply-To: <1467705603.2978.22.camel@pengutronix.de>
On 07/05/2016 01:30 PM, Philipp Zabel wrote:
> Hi Archit,
>
> thanks for the review!
>
> Am Dienstag, den 05.07.2016, 10:08 +0530 schrieb Archit Taneja:
> [...]
>>> +#include <drm/drmP.h>
>>
>> This may not be needed.
>
> I'll check and remove it.
>
>>> +#ifndef regmap_read_poll_timeout
>>> +#define regmap_read_poll_timeout(map, addr, val, cond, sleep_us, timeout_us) \
>>> +({ \
>>> + ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
>>> + int ret; \
>>> + might_sleep_if(sleep_us); \
>>> + for (;;) { \
>>> + ret = regmap_read((map), (addr), &(val)); \
>>> + if (ret) \
>>> + break; \
>>> + if (cond) \
>>> + break; \
>>> + if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
>>> + ret = regmap_read((map), (addr), &(val)); \
>>> + break; \
>>> + } \
>>> + if (sleep_us) \
>>> + usleep_range((sleep_us >> 2) + 1, sleep_us); \
>>> + } \
>>> + ret ?: ((cond) ? 0 : -ETIMEDOUT); \
>>> +})
>>> +#endif
>>
>> Is there a reason why this is wrapped around a #ifndef? I don't see it
>> in the current regmap.h headers. It would also be nice if it were made
>> into a function.
>
> This is a macro similar to those defined in iopoll.h. It can't be a
> function because the "cond"ition is specified by the caller and has to
> be evaluated in the loop.
> I'll submit this for regmap. If it doesn't get accepted I'll change this
> into two properly named functions.
>
> [...]
>>> +static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk)
>>> +{
>>> + int ret;
>>> + int i_pre, best_pre = 1;
>>> + int i_post, best_post = 1;
>>> + int div, best_div = 1;
>>> + int mul, best_mul = 1;
>>> + int delta, best_delta;
>>> + int ext_div[] = {1, 2, 3, 5, 7};
>>> + int best_pixelclock = 0;
>>> + int vco_hi = 0;
>>> + int pixelclock;
>>> +
>>> + pixelclock = tc->pll_clk;
>>> +
>>> + dev_dbg(tc->dev, "PLL: requested %d pixelclock, ref %d\n", pixelclock,
>>> + refclk);
>>> + best_delta = pixelclock;
>>> + /* big loops */
>>
>> The above comment could be improved.
>
> Will do.
>
>>> + for (i_pre = 0; i_pre < ARRAY_SIZE(ext_div); i_pre++) {
>>> + /* refclk / ext_pre_div should be in the 1 to 200 MHz range */
>>> + if ((refclk / ext_div[i_pre] > 200000000) ||
>>
>> The > 200 Mhz check seems redundant, since no refclk beyond 38.4 Mhz is
>> supported.
>
> Indeed. I'll drop the check and update the comment.
>
>>> + (refclk / ext_div[i_pre] < 1000000))
>>> + continue;
>>> + for (i_post = 0; i_post < ARRAY_SIZE(ext_div); i_post++) {
>>> + for (div = 1; div <= 16; div++) {
>>> + u32 clk;
>>> + u64 tmp;
>>> +
>>> + tmp = pixelclock * ext_div[i_pre] *
>>> + ext_div[i_post] * div;
>>> + do_div(tmp, refclk);
>>> + mul = tmp;
>>> +
>>> + clk = refclk / ext_div[i_pre] / div * mul /
>>> + ext_div[i_post];
>>
>> Some braces for the above expression might help :)
>
> Ok.
>
>>> + delta = clk - pixelclock;
>>> +
>>> + /* check limits */
>>> + if ((mul < 1) ||
>>> + (mul > 128))
>>
>> minor comment: the above check could be in a single line.
>
> Oversight, will fix.
>
> [...]
>>> +static int tc_aux_link_setup(struct tc_data *tc)
>>> +{
>>> + unsigned long rate;
>>> + u32 value;
>>> + int ret;
>>> +
>>> + rate = clk_get_rate(tc->refclk);
>>
>> Ah, you can discard my comment on the clock binding in the DT patch.
>> I guess you needed it to figure out the rate.
>
> Alright, going back to the other mail and updating my answer.
>
>>> + switch (rate) {
>>> + case 38400000:
>>> + value = REF_FREQ_38M4;
>>> + break;
>>> + case 26000000:
>>> + value = REF_FREQ_26M;
>>> + break;
>>> + case 19200000:
>>> + value = REF_FREQ_19M2;
>>> + break;
>>> + case 13000000:
>>> + value = REF_FREQ_13M;
>>> + break;
>>> + default:
>>> + dev_err(tc->dev, "Invalid refclk rate: %lu Hz\n", rate);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + /* Setup DP-PHY / PLL */
>>> + value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
>>> + tc_write(SYS_PLLPARAM, value);
>>> +
>>> + tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | BIT(2) | PHY_A0_EN);
>>
>> It seems a bit strange to have BIT(2) besides the other predefined
>> macros.
>
> I accidentally lost the comment when shortening this, BIT(2) is reserved
> but set.
>
> [...]
>>> + /* PXL PLL setup */
>>> + if (tc->test_pattern) {
>>
>> I couldn't find out who is setting tc->test_pattern. Is it always
>> 0?
>
> Hm, you are right. I wonder what a good mechanism would be to enable a
> test pattern for a bridge driver. Module parameters? We don't have
> anyhting like V4L2_CID_TEST_PATTERN in drm. I could also drop test
> pattern support from the initial patch and submit it separately.
Module parameter sounds like a good option. Although, it seems like the
pll is enabled only when test_pattern is set. How does the bridge work
if the pll isn't enabled?
Archit
>
> [...]
>>> +static const struct drm_connector_helper_funcs tc_connector_helper_funcs = {
>>> + .get_modes = tc_connector_get_modes,
>>> + .mode_valid = tc_connector_mode_valid,
>>> + .best_encoder = tc_connector_best_encoder,
>>> +};
>>> +
>>> +static void tc_connector_destroy(struct drm_connector *connector)
>>> +{
>>> + drm_connector_unregister(connector);
>>> + drm_connector_cleanup(connector);
>>> +}
>>> +
>>> +static const struct drm_connector_funcs tc_connector_funcs = {
>>> + .dpms = drm_helper_connector_dpms,
>>> + .fill_modes = drm_helper_probe_single_connector_modes,
>>> + .detect = tc_connector_detect,
>>> + .destroy = tc_connector_destroy,
>>
>> Can we use atomic helpers where applicable?
>
> I have worked on this on i.MX6, which doesn't have atomic support merged
> yet. I'll test with Liu Ying's i.MX6 atomic modeset patches and update
> to atomic helpers here.
>
> regards
> Philipp
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-07-11 8:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-01 14:50 [PATCH 0/2] Toshiba TC358767 eDP bridge driver Philipp Zabel
[not found] ` <1467384610-29908-1-git-send-email-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2016-07-01 14:50 ` [PATCH 1/2] dt-bindings: tc358767: add DT documentation Philipp Zabel
2016-07-05 3:23 ` Archit Taneja
2016-07-05 7:59 ` Philipp Zabel
2016-07-01 14:50 ` [PATCH 2/2] drm/bridge: tc358767: Add DPI to eDP bridge driver Philipp Zabel
2016-07-05 4:38 ` Archit Taneja
2016-07-05 8:00 ` Philipp Zabel
2016-07-11 8:32 ` Archit Taneja [this message]
2016-07-11 8:44 ` Philipp Zabel
2016-07-11 8:46 ` Archit Taneja
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=57835993.4020709@codeaurora.org \
--to=architt@codeaurora.org \
--cc=Chris.Healy@zii.aero \
--cc=andrey.gusakov@cogentembedded.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=mark.rutland@arm.com \
--cc=p.zabel@pengutronix.de \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=treding@nvidia.com \
/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;
as well as URLs for NNTP newsgroup(s).