From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Adam Ford <aford173@gmail.com>
Cc: Linux-OMAP <linux-omap@vger.kernel.org>,
"Adam Ford" <adam.ford@logicpd.com>,
"David Airlie" <airlied@linux.ie>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Rob Herring" <robh+dt@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Benoît Cousson" <bcousson@baylibre.com>,
"Tony Lindgren" <tony@atomide.com>,
dri-devel@lists.freedesktop.org,
devicetree <devicetree@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm/omap: Migrate minimum FCK/PCK ratio from Kconfig to dts
Date: Tue, 28 May 2019 18:53:11 +0300 [thread overview]
Message-ID: <7ada0752-6f65-2906-cb29-a47c9490fd57@ti.com> (raw)
In-Reply-To: <CAHCN7xLzoCNW6q5yDCsqMHeNvdNegkGhd0N+q9+Gd8JUGbG=_g@mail.gmail.com>
Hi,
On 28/05/2019 18:09, Adam Ford wrote:
> On Tue, May 28, 2019 at 4:11 AM Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>
>> Hi,
>>
>> On 10/05/2019 22:42, Adam Ford wrote:
>>> Currently the source code is compiled using hard-coded values
>>> from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this
>>> clock divider value to be moved to the device tree and be changed
>>> without having to recompile the kernel.
>>>
>>> Signed-off-by: Adam Ford <aford173@gmail.com>
>>
>> I understand why you want to do this, but I'm not sure it's a good idea.
>> It's really something the driver should figure out, and if we add it to
>> the DT, it effectively becomes an ABI.
>>
>> That said... I'm not sure how good of a job the driver could ever do, as
>> it can't know the future scaling needs of the userspace at the time it
>> is configuring the clock. And so, I'm not nacking this patch, but I
>> don't feel very good about this patch...
>>
>> The setting also affects all outputs (exluding venc), which may not be
>> what the user wants. Then again, I think this setting is really only
>> needed on OMAP2 & 3, which have only a single output. But that's the
>> same with the current kconfig option, of course.
>>
>> So, the current CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK is an ugly hack, in my
>> opinion, and moving it to DT makes it a worse hack =). But I don't have
>> any good suggestions either.
>
> As it stands the Logic PD OMAP35 and AM37/DM37 boards (SOM-LV and
> Torpedo) require this to be hard coded to 4 or it hangs during start.
> This is the case for all versions 4.2+. I haven't tested it with
> older stuff. Tony has a DM3730 Torpedo kit and reported the hanging
> issue to me. I told him to set that value to 4 to make it not hang.
> He asked that I move it to the DT to avoid custom kernels. I agree
> it's a hack, but if it's create a customized defconfig file for 4
> boards or modify the device tree, it seems like the device tree
> approach is less intrusive.
Ok, well, I think that's a separate thing from its intended use. The
point of the kconfig option is to ensure that the fclk/pclk ratio stays
under a certain number to allow enough scaling range. It should never
affect a basic non-scaling use case, unless you set it to a too high
value, which prevents finding any pclk.
Has anyone debugged why the hang is happening?
If we can't fix the bug itself, rather than adding a DT option, we could
change add a min_fck_per_pck field (as you do), keep the kconfig option,
and set the min_fck_per_pck based on the kconfig option, _or_ in case of
those affected SoCs, set the min_fck_per_pck even without the kconfig
option.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
next prev parent reply other threads:[~2019-05-28 15:53 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-10 19:42 [PATCH] drm/omap: Migrate minimum FCK/PCK ratio from Kconfig to dts Adam Ford
2019-05-28 11:11 ` Tomi Valkeinen
2019-05-28 15:09 ` Adam Ford
2019-05-28 15:20 ` H. Nikolaus Schaller
2019-05-28 15:53 ` Tomi Valkeinen [this message]
2019-05-31 12:13 ` Adam Ford
2019-09-25 20:51 ` Adam Ford
2019-09-26 6:55 ` Tomi Valkeinen
2019-09-26 14:12 ` Adam Ford
2019-09-27 6:21 ` Tomi Valkeinen
2019-09-27 12:13 ` Adam Ford
2019-09-27 13:45 ` Tomi Valkeinen
2019-09-27 7:55 ` Tomi Valkeinen
2019-09-27 12:33 ` Adam Ford
2019-09-27 13:47 ` Tomi Valkeinen
2019-09-27 15:37 ` Tero Kristo
2019-09-27 15:47 ` Tomi Valkeinen
2019-09-30 6:45 ` Tomi Valkeinen
2019-09-30 8:53 ` Tero Kristo
2019-09-30 12:41 ` Adam Ford
2019-09-30 12:47 ` Tero Kristo
2019-09-30 13:17 ` Adam Ford
2019-09-30 13:35 ` Tomi Valkeinen
2019-09-30 13:38 ` H. Nikolaus Schaller
2019-09-30 13:54 ` Adam Ford
2019-09-30 14:04 ` Adam Ford
2019-09-30 14:12 ` Adam Ford
2019-09-30 14:20 ` Tomi Valkeinen
2019-09-30 14:27 ` Tomi Valkeinen
2019-09-30 14:56 ` H. Nikolaus Schaller
2019-09-30 15:10 ` Adam Ford
2019-09-30 17:48 ` Tero Kristo
2019-10-01 5:07 ` Tomi Valkeinen
2019-10-01 5:12 ` Tero Kristo
2019-10-01 8:12 ` Tero Kristo
2019-10-01 9:31 ` Tomi Valkeinen
2019-10-01 13:06 ` Adam Ford
2019-10-01 13:14 ` Tomi Valkeinen
2019-09-25 21:26 ` Andrew F. Davis
2019-06-13 20:22 ` Rob Herring
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=7ada0752-6f65-2906-cb29-a47c9490fd57@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=adam.ford@logicpd.com \
--cc=aford173@gmail.com \
--cc=airlied@linux.ie \
--cc=bcousson@baylibre.com \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=tony@atomide.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).