From: Andy Yan <andy.yan@rock-chips.com> To: Philipp Zabel <p.zabel@pengutronix.de> Cc: airlied@linux.ie, heiko@sntech.de, fabio.estevam@freescale.com, rmk+kernel@arm.linux.org.uk, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Grant Likely <grant.likely@linaro.org>, Rob Herring <robh+dt@kernel.org>, Shawn Guo <shawn.guo@linaro.org>, Josh Boyer <jwboyer@redhat.com>, Sean Paul <seanpaul@chromium.org>, Inki Dae <inki.dae@samsung.com>, Dave Airlie <airlied@redhat.com>, Arnd Bergmann <arnd@arndb.de>, Lucas Stach <l.stach@pengutronix.de>, Zubair.Kakakhel@imgtec.com, djkurtz@google.com, ykk@rock-chips.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, devel@driverdev.osuosl.org, devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org, jay.xu@rock-chips.com, Pawel Moll <pawel.moll@arm.com>, mark.yao@rock-chips.com, Mark Rutland <mark.rutland@arm.com>, vladimir_zapolskiy@mentor.com, Ian Campbell <ijc+devicetree@hellion.org.uk>, Kumar Gala <galak@codeaurora.org> Subject: Re: [PATCH v15 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support Date: Wed, 03 Dec 2014 20:32:15 +0800 [thread overview] Message-ID: <547F02CF.9010804@rock-chips.com> (raw) In-Reply-To: <1417525257.3411.12.camel@pengutronix.de> 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 > > > >
WARNING: multiple messages have this Message-ID (diff)
From: Andy Yan <andy.yan@rock-chips.com> To: Philipp Zabel <p.zabel@pengutronix.de> Cc: Mark Rutland <mark.rutland@arm.com>, heiko@sntech.de, airlied@linux.ie, dri-devel@lists.freedesktop.org, ykk@rock-chips.com, devel@driverdev.osuosl.org, Pawel Moll <pawel.moll@arm.com>, linux-rockchip@lists.infradead.org, Grant Likely <grant.likely@linaro.org>, Dave Airlie <airlied@redhat.com>, jay.xu@rock-chips.com, devicetree@vger.kernel.org, Zubair.Kakakhel@imgtec.com, Arnd Bergmann <arnd@arndb.de>, Ian Campbell <ijc+devicetree@hellion.org.uk>, Inki Dae <inki.dae@samsung.com>, Rob Herring <robh+dt@kernel.org>, Sean Paul <seanpaul@chromium.org>, rmk+kernel@arm.linux.org.uk, mark.yao@rock-chips.com, fabio.estevam@freescale.com, Josh Boyer <jwboyer@redhat.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-kernel@vger.kernel.org, djkurtz@google.com, Kumar Gala <galak@codeaurora.org>, Shawn Guo <shawn.guo@linaro.org>, vladimir_zapolskiy@mentor.com Subject: Re: [PATCH v15 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support Date: Wed, 03 Dec 2014 20:32:15 +0800 [thread overview] Message-ID: <547F02CF.9010804@rock-chips.com> (raw) In-Reply-To: <1417525257.3411.12.camel@pengutronix.de> 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 > > > > _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
next prev parent reply other threads:[~2014-12-03 12:32 UTC|newest] Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-12-02 7:36 [PATCH v15 0/12] dw-hdmi: convert imx hdmi to bridge/dw_hdmi Andy Yan 2014-12-02 7:36 ` Andy Yan 2014-12-02 7:38 ` [PATCH v15 01/12] drm: imx: imx-hdmi: make checkpatch happy Andy Yan 2014-12-02 7:38 ` Andy Yan 2014-12-02 7:39 ` [PATCH v15 02/12] drm: imx: imx-hdmi: return defer if can't get ddc i2c adapter Andy Yan 2014-12-02 7:39 ` Andy Yan 2014-12-02 7:39 ` [PATCH v15 03/12] drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode Andy Yan 2014-12-02 7:39 ` Andy Yan 2014-12-02 7:40 ` [PATCH v15 04/12] drm: imx: imx-hdmi: split phy configuration to platform driver Andy Yan 2014-12-02 7:40 ` Andy Yan 2014-12-02 7:41 ` [PATCH v15 05/12] drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi Andy Yan 2014-12-02 7:41 ` Andy Yan 2014-12-02 7:42 ` [PATCH v15 06/12] dt-bindings: add document for dw_hdmi Andy Yan 2014-12-02 7:42 ` Andy Yan 2014-12-02 18:23 ` Philipp Zabel 2014-12-02 18:23 ` Philipp Zabel 2014-12-03 0:54 ` Andy Yan 2014-12-03 0:54 ` Andy Yan 2014-12-03 9:19 ` Philipp Zabel 2014-12-03 9:19 ` Philipp Zabel 2014-12-03 9:43 ` Andy Yan 2014-12-03 9:43 ` Andy Yan 2014-12-03 9:46 ` Andy Yan 2014-12-03 9:46 ` Andy Yan 2014-12-03 11:52 ` Philipp Zabel 2014-12-03 11:52 ` Philipp Zabel 2014-12-03 11:58 ` Andy Yan 2014-12-03 11:58 ` Andy Yan 2014-12-02 7:42 ` [PATCH v15 07/12] drm: bridge/dw_hdmi: add support for multi-byte register width access Andy Yan 2014-12-02 7:43 ` [PATCH v15 08/12] drm: bridge/dw_hdmi: add mode_valid support Andy Yan 2014-12-02 7:43 ` Andy Yan 2014-12-02 7:43 ` [PATCH v15 09/12] drm: bridge/dw_hdmi: clear i2cmphy_stat0 reg in hdmi_phy_wait_i2c_done Andy Yan 2014-12-02 7:43 ` Andy Yan 2014-12-02 7:44 ` [PATCH v15 10/12] drm: bridge/dw_hdmi: add function dw_hdmi_phy_enable_spare Andy Yan 2014-12-02 7:44 ` Andy Yan 2014-12-02 7:44 ` [PATCH v15 11/12] dt-bindings: Add documentation for rockchip dw hdmi Andy Yan 2014-12-02 7:44 ` Andy Yan 2014-12-02 7:45 ` [PATCH v15 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support Andy Yan 2014-12-02 7:45 ` Andy Yan 2014-12-02 10:24 ` Philipp Zabel 2014-12-02 10:24 ` Philipp Zabel 2014-12-02 12:34 ` Andy Yan 2014-12-02 12:34 ` Andy Yan 2014-12-02 13:00 ` Philipp Zabel 2014-12-02 13:00 ` Philipp Zabel 2014-12-03 12:32 ` Andy Yan [this message] 2014-12-03 12:32 ` Andy Yan 2014-12-03 13:09 ` Philipp Zabel 2014-12-03 13:09 ` Philipp Zabel 2014-12-03 13:20 ` Andy Yan 2014-12-03 13:20 ` Andy Yan
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=547F02CF.9010804@rock-chips.com \ --to=andy.yan@rock-chips.com \ --cc=Zubair.Kakakhel@imgtec.com \ --cc=airlied@linux.ie \ --cc=airlied@redhat.com \ --cc=arnd@arndb.de \ --cc=devel@driverdev.osuosl.org \ --cc=devicetree@vger.kernel.org \ --cc=djkurtz@google.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=fabio.estevam@freescale.com \ --cc=galak@codeaurora.org \ --cc=grant.likely@linaro.org \ --cc=gregkh@linuxfoundation.org \ --cc=heiko@sntech.de \ --cc=ijc+devicetree@hellion.org.uk \ --cc=inki.dae@samsung.com \ --cc=jay.xu@rock-chips.com \ --cc=jwboyer@redhat.com \ --cc=l.stach@pengutronix.de \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rockchip@lists.infradead.org \ --cc=mark.rutland@arm.com \ --cc=mark.yao@rock-chips.com \ --cc=p.zabel@pengutronix.de \ --cc=pawel.moll@arm.com \ --cc=rmk+kernel@arm.linux.org.uk \ --cc=robh+dt@kernel.org \ --cc=seanpaul@chromium.org \ --cc=shawn.guo@linaro.org \ --cc=vladimir_zapolskiy@mentor.com \ --cc=ykk@rock-chips.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.