Tegra20/Tegra30 have no dedicated MIPI calibration device and calibration
registers are incorporated into CSI. Lets reuse Tegra114 calibration
framework and add Tegra20/Tegra30 as a special case.
Signed-off-by: Svyatoslav Ryhel <redacted>
---
drivers/gpu/host1x/mipi.c | 82 +++++++++++++++++++++++++++++++++++++++
1 file changed, 82 insertions(+)
@@ -525,6 +599,14 @@ static int tegra_mipi_probe(struct platform_device *pdev)returnPTR_ERR(mipi->clk);}+if(mipi->soc->dsi_v0){+mipi->csi_clk=devm_clk_get_prepared(&pdev->dev,"csi");+if(IS_ERR(mipi->csi_clk)){+dev_err(&pdev->dev,"failed to get CSI clock\n");+returnPTR_ERR(mipi->csi_clk);+}+}+platform_set_drvdata(pdev,mipi);return0;
@@ -74,6 +74,16 @@ vi@54080000 {status="disabled";};+/* DSI MIPI calibration logic is a part of VI/CSI */+mipi:mipi@54080220{+compatible="nvidia,tegra20-mipi";+reg=<0x540802200x100>;+clocks=<&tegra_carTEGRA20_CLK_VI>,+<&tegra_carTEGRA20_CLK_CSI>;+clock-names="vi","csi";+#nvidia,mipi-calibrate-cells=<1>;+};+epp@540c0000{compatible="nvidia,tegra20-epp";reg=<0x540c00000x00040000>;
@@ -164,6 +164,16 @@ vi@54080000 {status="disabled";};+/* DSI MIPI calibration logic is a part of VI/CSI */+mipi:mipi@54080220{+compatible="nvidia,tegra30-mipi";+reg=<0x540802200x100>;+clocks=<&tegra_carTEGRA30_CLK_VI>,+<&tegra_carTEGRA30_CLK_CSI>;+clock-names="vi","csi";+#nvidia,mipi-calibrate-cells=<1>;+};+epp@540c0000{compatible="nvidia,tegra30-epp";reg=<0x540c00000x00040000>;
@@ -74,6 +74,16 @@ vi@54080000 {status="disabled";};+/* DSI MIPI calibration logic is a part of VI/CSI */+mipi:mipi@54080220{+compatible="nvidia,tegra20-mipi";+reg=<0x540802200x100>;+clocks=<&tegra_carTEGRA20_CLK_VI>,+<&tegra_carTEGRA20_CLK_CSI>;+clock-names="vi","csi";+#nvidia,mipi-calibrate-cells=<1>;+};+
As you say in the comment, MIPI calibration on Tegra20/30 is part of VI/CSI.
We can't add a "mipi" device here since such a device doesn't exist in the
hardware hierarchy. We already have the VI device in the device tree, so we
need to use that.
A driver for tegra20-vi already exists in staging/drivers/media/tegra-video.
We should aim not to break it. Perhaps bring it out of staging? (At least
partially, but then why not the whole thing.)
Thanks,
Mikko
Where does this sequence come from? It looks a bit strange to me, since it
doesn't trigger calibration at all. It would be useful to mention the source
in the commit message.
Mikko
@@ -74,6 +74,16 @@ vi@54080000 {status="disabled";};+/* DSI MIPI calibration logic is a part of VI/CSI */+mipi:mipi@54080220{+compatible="nvidia,tegra20-mipi";+reg=<0x540802200x100>;+clocks=<&tegra_carTEGRA20_CLK_VI>,+<&tegra_carTEGRA20_CLK_CSI>;+clock-names="vi","csi";+#nvidia,mipi-calibrate-cells=<1>;+};+
As you say in the comment, MIPI calibration on Tegra20/30 is part of VI/CSI.
We can't add a "mipi" device here since such a device doesn't exist in the
hardware hierarchy. We already have the VI device in the device tree, so we
need to use that.
I understand your point, but embedding MIPI calibration logic into
VI/CSI driver will bring up another lever of unnecessary complexity
and excessive coding. While approach I have proposed preserves
separation between CSI and DSI and reuses already existing MIPI
calibration framework.
A driver for tegra20-vi already exists in staging/drivers/media/tegra-video.
We should aim not to break it. Perhaps bring it out of staging? (At least
partially, but then why not the whole thing.)
It does not break VI/CSI, I have a WIP CSI implementation for
Tegra20/Tegra30 which I hope to submit soon.
Where does this sequence come from? It looks a bit strange to me, since it
doesn't trigger calibration at all. It would be useful to mention the source
in the commit message.
Mikko
Downstream nvidia sources, 3.1.10 and 3.4, dsi driver, function
tegra_dsi_pad_calibration
@@ -74,6 +74,16 @@ vi@54080000 {status="disabled";};+/* DSI MIPI calibration logic is a part of VI/CSI */+mipi:mipi@54080220{+compatible="nvidia,tegra20-mipi";+reg=<0x540802200x100>;+clocks=<&tegra_carTEGRA20_CLK_VI>,+<&tegra_carTEGRA20_CLK_CSI>;+clock-names="vi","csi";+#nvidia,mipi-calibrate-cells=<1>;+};+
As you say in the comment, MIPI calibration on Tegra20/30 is part of
VI/CSI. We can't add a "mipi" device here since such a device doesn't
exist in the hardware hierarchy. We already have the VI device in the
device tree, so we need to use that.
I understand your point, but embedding MIPI calibration logic into
VI/CSI driver will bring up another lever of unnecessary complexity
and excessive coding. While approach I have proposed preserves
separation between CSI and DSI and reuses already existing MIPI
calibration framework.
We can consider different driver architectures to simplify things, but the
device tree has to conform to hardware. The host1x bus has no 'mipi' device on
it so we can't put one in the device tree.
quoted
A driver for tegra20-vi already exists in
staging/drivers/media/tegra-video. We should aim not to break it. Perhaps
bring it out of staging? (At least partially, but then why not the whole
thing.)
It does not break VI/CSI, I have a WIP CSI implementation for
Tegra20/Tegra30 which I hope to submit soon.
We have to use the tegra20-vi node as that matches hardware, and each node can
only be probed to one device, hence the issue.
Great to see a CSI driver!
Mikko
@@ -74,6 +74,16 @@ vi@54080000 {status="disabled";};+/* DSI MIPI calibration logic is a part of VI/CSI */+mipi:mipi@54080220{+compatible="nvidia,tegra20-mipi";+reg=<0x540802200x100>;+clocks=<&tegra_carTEGRA20_CLK_VI>,+<&tegra_carTEGRA20_CLK_CSI>;+clock-names="vi","csi";+#nvidia,mipi-calibrate-cells=<1>;+};+
As you say in the comment, MIPI calibration on Tegra20/30 is part of
VI/CSI. We can't add a "mipi" device here since such a device doesn't
exist in the hardware hierarchy. We already have the VI device in the
device tree, so we need to use that.
I understand your point, but embedding MIPI calibration logic into
VI/CSI driver will bring up another lever of unnecessary complexity
and excessive coding. While approach I have proposed preserves
separation between CSI and DSI and reuses already existing MIPI
calibration framework.
We can consider different driver architectures to simplify things, but the
device tree has to conform to hardware. The host1x bus has no 'mipi' device on
it so we can't put one in the device tree.
I assume then placing mipi node as CSI or VI child would resolve your concern?
quoted
quoted
A driver for tegra20-vi already exists in
staging/drivers/media/tegra-video. We should aim not to break it. Perhaps
bring it out of staging? (At least partially, but then why not the whole
thing.)
It does not break VI/CSI, I have a WIP CSI implementation for
Tegra20/Tegra30 which I hope to submit soon.
We have to use the tegra20-vi node as that matches hardware, and each node can
only be probed to one device, hence the issue.
Great to see a CSI driver!
Mikko
Where does this sequence come from? It looks a bit strange to me, since it
doesn't trigger calibration at all. It would be useful to mention the
source in the commit message.
Mikko
Downstream nvidia sources, 3.1.10 and 3.4, dsi driver, function
tegra_dsi_pad_calibration
Thanks!
Indeed, looks like for DSI calibration, the HW calibration is never triggered.
However, for CSI pads, it is. We should take this into account in the device
tree binding (and driver when CSI support is added) -- the parameter in
nvidia,mipi-calibrate should specify we're calibrating DSI (probably with an
enumeration defined in a header file).
Another thing -- the commit subject prefix for gpu/host1x is "gpu: host1x: ",
and for gpu/drm/tegra "drm/tegra: ".
Cheers,
Mikko
@@ -74,6 +74,16 @@ vi@54080000 {status="disabled";};+/* DSI MIPI calibration logic is a part of VI/CSI */+mipi:mipi@54080220{+compatible="nvidia,tegra20-mipi";+reg=<0x540802200x100>;+clocks=<&tegra_carTEGRA20_CLK_VI>,+<&tegra_carTEGRA20_CLK_CSI>;+clock-names="vi","csi";+#nvidia,mipi-calibrate-cells=<1>;+};+
As you say in the comment, MIPI calibration on Tegra20/30 is part of
VI/CSI. We can't add a "mipi" device here since such a device doesn't
exist in the hardware hierarchy. We already have the VI device in the
device tree, so we need to use that.
I understand your point, but embedding MIPI calibration logic into
VI/CSI driver will bring up another lever of unnecessary complexity
and excessive coding. While approach I have proposed preserves
separation between CSI and DSI and reuses already existing MIPI
calibration framework.
We can consider different driver architectures to simplify things, but the
device tree has to conform to hardware. The host1x bus has no 'mipi'
device on it so we can't put one in the device tree.
I assume then placing mipi node as CSI or VI child would resolve your
concern?
The device tree is not intended to follow software architecture. Having a
separate device node implies some sort of bus / parent-child hierarchy in
hardware. So it seems a little difficult to justify.
In this case, it seems to me that it would be pretty easy to add/partially
copy a small VI driver while integrating with the staging driver, based on how
simple its probe function is. And given that you're planning on adding CSI
support as well, utilizing the tegra-video driver seems like it's in the cards
anyway.
Thanks,
Mikko
quoted
quoted
quoted
A driver for tegra20-vi already exists in
staging/drivers/media/tegra-video. We should aim not to break it.
Perhaps
bring it out of staging? (At least partially, but then why not the
whole
thing.)
It does not break VI/CSI, I have a WIP CSI implementation for
Tegra20/Tegra30 which I hope to submit soon.
We have to use the tegra20-vi node as that matches hardware, and each node
can only be probed to one device, hence the issue.
Great to see a CSI driver!
Mikko
@@ -525,6 +599,14 @@ static int tegra_mipi_probe(struct platform_device *pdev) return PTR_ERR(mipi->clk); }+ if (mipi->soc->dsi_v0) {+ mipi->csi_clk = devm_clk_get_prepared(&pdev->dev, "csi");+ if (IS_ERR(mipi->csi_clk)) {
Doesn't look like the clock needs to be prepared. Normally, you would
need to have clock prepared if clock is enabled/disabled from a context
that can't sleep, like under spinlock or in IRQ handler. AFAICT, this
not the case here.