linux-kernel - Re: [PATCH v15 12/12] drm: bridge/dw

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: <547F02CF.9010804@rock-chips.com>
Date:	Wed, 03 Dec 2014 20:32:15 +0800
From:	Andy Yan <andy.yan@...k-chips.com>
To:	Philipp Zabel <p.zabel@...gutronix.de>
CC:	airlied@...ux.ie, heiko@...ech.de, fabio.estevam@...escale.com,
	rmk+kernel@....linux.org.uk,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Shawn Guo <shawn.guo@...aro.org>,
	Josh Boyer <jwboyer@...hat.com>,
	Sean Paul <seanpaul@...omium.org>,
	Inki Dae <inki.dae@...sung.com>,
	Dave Airlie <airlied@...hat.com>,
	Arnd Bergmann <arnd@...db.de>,
	Lucas Stach <l.stach@...gutronix.de>,
	Zubair.Kakakhel@...tec.com, djkurtz@...gle.com, ykk@...k-chips.com,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	devel@...verdev.osuosl.org, devicetree@...r.kernel.org,
	linux-rockchip@...ts.infradead.org, jay.xu@...k-chips.com,
	Pawel Moll <pawel.moll@....com>, mark.yao@...k-chips.com,
	Mark Rutland <mark.rutland@....com>,
	vladimir_zapolskiy@...tor.com,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>
Subject: Re: [PATCH v15 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support

Hi Philipp:
On 2014年12月02日 21:00, Philipp Zabel wrote:
> Hi Andy,
>
> Am Dienstag, den 02.12.2014, 20:34 +0800 schrieb Andy Yan:
>> Hi Philipp:
>> On 2014年12月02日 18:24, Philipp Zabel wrote:
>>> Hi Andy,
>>>
>>> Am Dienstag, den 02.12.2014, 15:45 +0800 schrieb Andy Yan:
>>> [...]
>>>> +static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
>>>> +				 void *data)
>>>> +{
>>>> +	struct platform_device *pdev = to_platform_device(dev);
>>>> +	const struct dw_hdmi_plat_data *plat_data;
>>>> +	const struct of_device_id *match;
>>>> +	struct drm_device *drm = data;
>>>> +	struct drm_encoder *encoder;
>>>> +	struct rockchip_hdmi *hdmi;
>>>> +	int ret;
>>>> +
>>>> +	if (!pdev->dev.of_node)
>>>> +		return -ENODEV;
>>>> +
>>>> +	hdmi = devm_kzalloc(&pdev->dev, sizeof(*hdmi), GFP_KERNEL);
>>>> +	if (!hdmi)
>>>> +		return -ENOMEM;
>>>> +
>>>> +	match = of_match_node(dw_hdmi_rockchip_ids, pdev->dev.of_node);
>>>> +	plat_data = match->data;
>>>> +	hdmi->dev = &pdev->dev;
>>>> +	encoder = &hdmi->encoder;
>>>> +	platform_set_drvdata(pdev, hdmi);
>>>> +
>>>> +	ret = rockchip_hdmi_parse_dt(hdmi);
>>>> +	if (ret) {
>>>> +		dev_err(hdmi->dev, "Unable to parse OF data\n");
>>>> +		return ret;
>>>> +	}
>>>> +
>>>> +	ret = clk_prepare_enable(hdmi->clk);
>>>> +	if (ret) {
>>>> +		dev_err(hdmi->dev, "Cannot enable HDMI clock: %d\n", ret);
>>>> +		return ret;
>>>> +	}
>>>> +
>>>> +	ret = clk_prepare_enable(hdmi->hdcp_clk);
>>>> +	if (ret) {
>>>> +		dev_err(hdmi->dev, "Cannot enable HDMI hdcp clock: %d\n", ret);
>>>> +		return ret;
>>>> +	}
>>> Could we have a look at the clocks again? Basically the Rockchip clock
>>> handling is exactly the same, except the clocks are called by other
>>> names.
>>>
>>> On i.MX6, according to the reference manual, the HDMI TX module has four
>>> clock inputs: "iahbclk" (bus clock), "icecclk" (32 kHz CEC clock),
>>> "ihclk" (module clock), and "isfrclk" (27 MHz internal SFR clock).
>>> The "iahbclk" and "ihclk" are both sourced from the SoC AHB root clock,
>>> the 32 kHz reference input can't be gated, and the "isfrclk" has its own
>>> gate.
>>>
>>> Does the HDMI TX implementation on Rockchip still have the separate
>>> external sfr bus and module clock inputs? I assume that your "clk" input
>>> is a single gate bit for bus and module clocks at the same time?
>>> If possible, I'd prefer to find a common binding for the clocks with
>>> some of the clocks being optional, but for that we need to know the
>>> actual clock inputs to the HDMI TX module.
>>>
>>> regards
>>> Philipp
>>>
>>       There are three  individual clock inputs on Rockchip RK3288 HDMI:
>> "hdmi_ctrl_clk",
>>       "hdmi_cec_clk", "hdmi_hdcp_clk", the three clocks are responsible
>> for different
>>        functions as their name described, and have their own private gate
>> bit. That is
>>        to say, the cec_clk and hdcp_clk can all be disabled if we don't
>> need hdcp and cec
>>        function.
>>        So I think it's better to make the clk control platform independent.
> My question is not about the available gates at the SoC level, but about
> the actual clock inputs from point of view of the HDMI TX IP.
>
> It could be that the hdmi_ctrl_clk gates all inputs to the module and
> bus clocks together. If so, you could just reuse "isfr" and "iahb" and
> set it to the same clock. If not, we'd need to think of something else.
> Unfortunately I don't have any Synopsys documentation of the HDMI TX at
> that level.

    After confirming with the IC designer, we finally make clear that
    Rockchip RK3288 almost use the same clock design with imx:
    clk-----iahbclk, used for hdmi module and bus
    hdcp_clk-----isfrclk, used for hdcp and i2cm
    cecclk -----cecclk, but this clk can be gated on rockchip, this is 
different with imx,
    but we don't handle the cec stuff now. So i will try to reuse the 
imx clk binds. do you
   think that is ok?
> regards
> Philipp
>
>
>
>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/