| Message ID | 1389622894-9574-3-git-send-email-treding@nvidia.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 01/13/2014 07:21 AM, Thierry Reding wrote: > The head number of a given display controller is fixed in hardware and > required to program outputs appropriately. Relying on the driver probe > order to determine this number will not work, since that could yield a > situation where the second head was probed first and would be assigned > head number 0 instead of 1. This change makes the new properties mandatory, yet they aren't part of the DT files yet. So, won't this patch break all display on Tegra? To avoid having to modify the Tegra DTs in this patch, can't the code fall back to the existing broken algorithm if the property is missing, i.e.: > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c > - dc->pipe = tegra->drm->mode_config.num_crtc; Instead,: if (dc->pipe == -1) dc->pipe = tegra->drm->mode_config.num_crtc; > +static int tegra_dc_parse_dt(struct tegra_dc *dc) > +{ > + u32 value; > + int err; > + > + err = of_property_read_u32(dc->dev->of_node, "nvidia,head", &value); > + if (err < 0) > + return err; > + > + dc->pipe = value; Instead: err = ... if (!err) dc->pipe = value; else /* Perhaps also emit an error message here */ dc->pipe = -1;
On Mon, Jan 13, 2014 at 10:46:45AM -0700, Stephen Warren wrote: > On 01/13/2014 07:21 AM, Thierry Reding wrote: > > The head number of a given display controller is fixed in hardware and > > required to program outputs appropriately. Relying on the driver probe > > order to determine this number will not work, since that could yield a > > situation where the second head was probed first and would be assigned > > head number 0 instead of 1. > > This change makes the new properties mandatory, yet they aren't part of > the DT files yet. So, won't this patch break all display on Tegra? I don't think it'll make anything worse than it currently is, since both display controllers can't run at the same time with the current code. They can do so on Dalmore, so I guess that would be broken by the patch. > To avoid having to modify the Tegra DTs in this patch, can't the code > fall back to the existing broken algorithm if the property is missing, i.e.: > > > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c > > > - dc->pipe = tegra->drm->mode_config.num_crtc; > > Instead,: > > if (dc->pipe == -1) > dc->pipe = tegra->drm->mode_config.num_crtc; > > > +static int tegra_dc_parse_dt(struct tegra_dc *dc) > > +{ > > + u32 value; > > + int err; > > + > > + err = of_property_read_u32(dc->dev->of_node, "nvidia,head", &value); > > + if (err < 0) > > + return err; > > + > > + dc->pipe = value; > > Instead: > > err = ... > if (!err) > dc->pipe = value; > else > /* Perhaps also emit an error message here */ > dc->pipe = -1; Yeah, that should work. It's still suboptimal because we fallback to something that's broken and known not to work. My original proposal was to make the dc->pipe assignment depend on the physical address of the display controller's registers. That's ugly, but all SoCs in existence do use the very same offset. So we could reason that for anything that's still using the old DTB files we can rely on the physical address of the registers, while any new DTBs should include the new nvidia,head property. I have a feeling that you won't like it, though. One other method would be to iterate over all DT nodes that match the display controller compatible and use the index for the pipe number. That should fix the current issues, but is still a wee bit hackish because it assumes that nodes in DTB will be in the same order as in the DTS. That has been true since the beginning of DT on Linux AFAIK and therefore should be reasonably safe. Thierry
On 01/14/2014 07:14 AM, Thierry Reding wrote: > On Mon, Jan 13, 2014 at 10:46:45AM -0700, Stephen Warren wrote: >> On 01/13/2014 07:21 AM, Thierry Reding wrote: >>> The head number of a given display controller is fixed in hardware and >>> required to program outputs appropriately. Relying on the driver probe >>> order to determine this number will not work, since that could yield a >>> situation where the second head was probed first and would be assigned >>> head number 0 instead of 1. >> >> This change makes the new properties mandatory, yet they aren't part of >> the DT files yet. So, won't this patch break all display on Tegra? > > I don't think it'll make anything worse than it currently is, since both > display controllers can't run at the same time with the current code. Sure it will; it will prevent any dc device from probing at all: > +static int tegra_dc_parse_dt(struct tegra_dc *dc) ... > + err = of_property_read_u32(dc->dev->of_node, "nvidia,head", &value); > + if (err < 0) + return err; ^^^^^^^^^^^ ... > @@ -1207,6 +1219,10 @@ static int tegra_dc_probe(struct platform_device *pdev) ... > + err = tegra_dc_parse_dt(dc); > + if (err < 0) > + return err; ^^^^^^^^^^^
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt index 9e9008f8fa32..efaeec8961b6 100644 --- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt +++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt @@ -118,6 +118,9 @@ of the following host1x client modules: See ../reset/reset.txt for details. - reset-names: Must include the following entries: - dc + - nvidia,head: The number of the display controller head. This is used to + setup the various types of output to receive video data from the given + head. Each display controller node has a child node, named "rgb", that represents the RGB output associated with the controller. It can take the following diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index 386f3b4b0094..ce0d2c2c7aac 100644 --- a/drivers/gpu/drm/tegra/dc.c +++ b/drivers/gpu/drm/tegra/dc.c @@ -1100,8 +1100,6 @@ static int tegra_dc_init(struct host1x_client *client) struct tegra_dc *dc = host1x_client_to_dc(client); int err; - dc->pipe = tegra->drm->mode_config.num_crtc; - drm_crtc_init(tegra->drm, &dc->base, &tegra_crtc_funcs); drm_mode_crtc_set_gamma_size(&dc->base, 256); drm_crtc_helper_add(&dc->base, &tegra_crtc_helper_funcs); @@ -1160,6 +1158,20 @@ static const struct host1x_client_ops dc_client_ops = { .exit = tegra_dc_exit, }; +static int tegra_dc_parse_dt(struct tegra_dc *dc) +{ + u32 value; + int err; + + err = of_property_read_u32(dc->dev->of_node, "nvidia,head", &value); + if (err < 0) + return err; + + dc->pipe = value; + + return 0; +} + static const struct tegra_dc_soc_info tegra20_dc_soc_info = { .supports_interlacing = false, }; @@ -1207,6 +1219,10 @@ static int tegra_dc_probe(struct platform_device *pdev) dc->dev = &pdev->dev; dc->soc = id->data; + err = tegra_dc_parse_dt(dc); + if (err < 0) + return err; + dc->clk = devm_clk_get(&pdev->dev, NULL); if (IS_ERR(dc->clk)) { dev_err(&pdev->dev, "failed to get clock\n");
The head number of a given display controller is fixed in hardware and required to program outputs appropriately. Relying on the driver probe order to determine this number will not work, since that could yield a situation where the second head was probed first and would be assigned head number 0 instead of 1. Signed-off-by: Thierry Reding <treding@nvidia.com> --- .../bindings/gpu/nvidia,tegra20-host1x.txt | 3 +++ drivers/gpu/drm/tegra/dc.c | 20 ++++++++++++++++++-- 2 files changed, 21 insertions(+), 2 deletions(-)