linux-kernel - Re: [PATCH 0/5] clk: rockchip: add full support for HDMI clock on rk3288

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAD=FV=VB93wYigRJ8wa8YL6P+Q+-fRokPiCB-Fo1pC_zAdh2oA@mail.gmail.com>
Date:	Thu, 21 Jan 2016 12:11:00 -0800
From:	Doug Anderson <dianders@...omium.org>
To:	Tomeu Vizoso <tomeu@...euvizoso.net>
Cc:	Kever Yang <kever.yang@...k-chips.com>,
	Heiko Stübner <heiko@...ech.de>,
	Mike Turquette <mturquette@...aro.org>,
	Sonny Rao <sonnyrao@...omium.org>,
	Addy Ke <addy.ke@...k-chips.com>,
	Eddie Cai <cf@...k-chips.com>,
	ZhenFu Fang <fzf@...k-chips.com>,
	Yakir Yang <ykk@...k-chips.com>,
	姚智情 <yzq@...k-chips.com>,
	戴克霖 (Jack) <dkl@...k-chips.com>,
	Tao Huang <huangtao@...k-chips.com>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-clk <linux-clk@...r.kernel.org>
Subject: Re: [PATCH 0/5] clk: rockchip: add full support for HDMI clock on rk3288

Hi,

On Thu, Jan 21, 2016 at 1:03 AM, Tomeu Vizoso <tomeu@...euvizoso.net> wrote:
> So we have a mechanism for detecting a conflict in the clock
> hierarchy, and a mechanism to solve it, but we are missing a way for
> userspace to communicate policy regarding which clocks should be given
> priority when solving such a conflict?

Hrmmm, I guess it could be userspace that makes the decision.  It does
seem a little odd to force it to userspace in all cases, though.  For
a particular laptop that is designed with a specific panel connected
up eDP it seems less than ideal to push this into userspace.  If the
kernel could just work in the expected sane way (or at least work that
way by default) it would be ideal.

If the kernel doesn't try to do anything sane by default then you're
creating a requirement for everyone's userspace to somehow figure this
out.  Do you expect there to be UI here, or that this would be
something that would be figured out by the Linux distribution?
Certainly exposing UI on something like a laptop with a builtin panel
wouldn't make any sense to me, but it might make sense if you had an
eval board with different display connectors on it.  If there's no UI,
would the Linux distribution need to somehow identify which board we
were on and then have a big lookup table about how to configure
things?