devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, Cyprian Wronka <cwronka@cadence.com>,
	Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Simon Hatliff <hatliff@cadence.com>,
	dri-devel@lists.freedesktop.org,
	Richard Sproul <sproul@cadence.com>,
	Alan Douglas <adouglas@cadence.com>,
	Rob Herring <robh+dt@kernel.org>,
	Kumar Gala <galak@codeaurora.org>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Neil Webb <neilw@cadence.com>
Subject: Re: [PATCH v2 1/2] drm/bridge: Add Cadence DSI driver
Date: Tue, 6 Jun 2017 16:08:07 +0200	[thread overview]
Message-ID: <20170606160807.4e717916@bbrezillon> (raw)
In-Reply-To: <cc37dbaf-8a6b-eb2c-81d4-87a290c56a25@ti.com>

On Tue, 6 Jun 2017 16:30:15 +0300
Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:

> On 02/06/17 15:04, Boris Brezillon wrote:
> 
> > +enum cdns_dsi_output_type {
> > +	CDNS_DSI_PANEL = 0,
> > +	CDNS_DSI_BRIDGE = 1,
> > +};  
> 
> Just my opinion, but I think you should only define values for enums
> when those values actually mean something and are needed. In this case,
> it doesn't matter which values those enums have.

Actually, this will go away in the next version (see Archit's comment).

> 
> > +static int cdns_dsi_init_link(struct cdns_dsi *dsi)
> > +{
> > +	u32 val;
> > +	int i;
> > +
> > +	writel(CLK_UNIT_INTERVAL(16), dsi->regs + MCTL_DPHY_STATIC);
> > +	writel(CLK_DIV(0xb) | HSTX_TIMEOUT(0xed8afff),
> > +	       dsi->regs + MCTL_DPHY_TIMEOUT1);
> > +	writel(LPRX_TIMEOUT(0xf30fffff), dsi->regs + MCTL_DPHY_TIMEOUT2);
> > +
> > +	val = WAIT_BURST_TIME(0xf);
> > +	for (i = 1; i < dsi->output->dev->lanes; i++)
> > +		val |= DATA_LANE_EN(i);
> > +
> > +	if (!(dsi->output->dev->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS))
> > +		val |= CLK_CONTINUOUS;
> > +
> > +	writel(val, dsi->regs + MCTL_MAIN_PHY_CTL);
> > +
> > +	writel(CLK_LANE_ULPOUT_TIME(0x105) | DATA_LANE_ULPOUT_TIME(0x1d5),
> > +	       dsi->regs + MCTL_ULPOUT_TIME);
> > +
> > +	writel(LINK_EN, dsi->regs + MCTL_MAIN_DATA_CTL);
> > +
> > +	val = CLK_LANE_EN | PLL_START;
> > +	for (i = 0; i < dsi->output->dev->lanes; i++)
> > +		val |= DATA_LANE_START(i);
> > +
> > +	writel(val, dsi->regs + MCTL_MAIN_EN);
> > +
> > +	ndelay(100);
> > +
> > +	return 0;
> > +}  
> 
> There are quite a bit of magic values here (elsewhere too). Looking at
> the names of the macros, many of them probably represent spans of time,
> in clock ticks? Would it make more sense to have the times defined in,
> say, nanoseconds, and a function to convert the ns to clock ticks?
> 
> And a hardcoded CLK_DIV, does that work? Is the clock rate fixed?

Okay, it seems I have all the necessary information to dynamically
calculate ULPOUT_TIME values (these values are based on sysclk and
ULPOUT_TIME should be 1ms).

It's a bit more complicated for MCTL_DPHY_TIMEOUT1 and
MCTL_DPHY_TIMEOUT2, because counters are based on the dsi_tx_byte clock
which is derived from the DPHY PLL, and I don't have the final
spec of the DPHY block yet, which means I can't extract the dsi_tx_byte
clock rate.
A temporary solution would be to hardcore the tx_byte_clk in the driver
and do all the calculation based on this hardcoded value. Or maybe we
should expose the DPHY PLL in the DT.

I also don't know what CLK_UNIT_INTERVAL() is encoding. I'll check with
Cadence engineers.

Thanks,

Boris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

      reply	other threads:[~2017-06-06 14:08 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-02 12:04 [PATCH v2 1/2] drm/bridge: Add Cadence DSI driver Boris Brezillon
     [not found] ` <1496405096-18275-1-git-send-email-boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2017-06-02 12:04   ` [PATCH v2 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings Boris Brezillon
2017-06-03 18:13     ` Archit Taneja
2017-06-06  9:35       ` Boris Brezillon
2017-06-06 12:40         ` Tomi Valkeinen
     [not found]           ` <902ba6cf-4125-fac6-62dd-6b6198f541f3-l0cyMroinI0@public.gmane.org>
2017-06-06 12:48             ` Boris Brezillon
2017-06-06 12:58               ` Tomi Valkeinen
     [not found]                 ` <9ca829e6-4696-7c3a-aed3-6a2af3161557-l0cyMroinI0@public.gmane.org>
2017-06-13  9:02                   ` Andrzej Hajda
     [not found]                     ` <cb4c3bc1-5c61-25dd-a229-64753de68af4-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2017-06-19 10:12                       ` Boris Brezillon
2017-06-20  6:56                         ` Archit Taneja
     [not found]                           ` <44b693f5-152e-cb0c-4a99-c8d1b0d8e3d9-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-06-20  7:22                             ` Andrzej Hajda
2017-06-14  3:44                 ` Archit Taneja
     [not found]     ` <1496405096-18275-2-git-send-email-boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2017-06-06 12:30       ` Tomi Valkeinen
     [not found]         ` <62284d00-c204-dc2e-a780-0357b2094b62-l0cyMroinI0@public.gmane.org>
2017-06-06 12:37           ` Boris Brezillon
2017-06-06 13:01             ` Tomi Valkeinen
     [not found]               ` <99525652-0270-4eb0-73bc-c65ac51bc39e-l0cyMroinI0@public.gmane.org>
2017-06-06 13:06                 ` Boris Brezillon
2017-06-03 18:50   ` [PATCH v2 1/2] drm/bridge: Add Cadence DSI driver Archit Taneja
     [not found]     ` <29776d56-b6ae-9f92-0b94-8c55b46169fd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-06-06 10:20       ` Boris Brezillon
2017-06-14  4:02         ` Archit Taneja
2017-06-06 13:30   ` Tomi Valkeinen
2017-06-06 14:08     ` Boris Brezillon [this message]

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=20170606160807.4e717916@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=adouglas@cadence.com \
    --cc=cwronka@cadence.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=galak@codeaurora.org \
    --cc=hatliff@cadence.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=maxime.ripard@free-electrons.com \
    --cc=neilw@cadence.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=sproul@cadence.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=tomi.valkeinen@ti.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).