Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
Hi Jagan,
On 20/01/2022 12:03, Jagan Teki wrote:
> On Wed, Jan 12, 2022 at 1:49 PM Neil Armstrong
> wrote:
>>
>> Hi,
>>
>> On 12/01/2022 08:24, Jagan Teki wrote:
>>> Hi Neil,
>>>
>>> On Mon, Sep 7, 2020 at 1:48 PM Neil Armstrong
>>> wrote:
The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver
1.21a), with a custom
glue managing the IP resets, clock and data input similar to the DW-HDMI
Glue on other
Amlogic SoCs.
This adds support for the Glue managing the transceiver, mimicing the init
flow provided
by Amlogic to setup the ENCl encoder, the glue, the transceiver, the
digital D-PHY and the
Analog PHY in the proper way.
The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2
clock, which pixel clock
is derived and feeds the ENCL encoder and the VIU pixel reader.
An optional "MEAS" clock can be enabled to measure the delay between each
vsync feeding the
DW-MIPI-DSI transceiver.
Signed-off-by: Neil Armstrong
---
>>
>> [..]
>>
+
+static const struct component_ops meson_dw_mipi_dsi_ops = {
+ .bind = meson_dw_mipi_dsi_bind,
+ .unbind = meson_dw_mipi_dsi_unbind,
+};
>>>
>>> Do you thought of non-component based meson DSI like STM DSI? It
>>> require changes from meson drm but just to understand if you have any
>>> such plan.
>>
>> I have no such plans for now, note this serie has been rewritten at [1] but
>> still
>> with based with components.
>>
>> If worth it, the plan is to get it with components and than yes if it's
>> simpler
>> drop components completely.
>
> Dropping components make the pipeline well suited for bridges as we
> are moving bridge-driven pipelines in other areas.
>
>>
>> I'll have a look at how ST does
>
> ST has no components. As I said above, eventually there would be
> common bridge driver for dw-mipi-dsi if meson and rockchip moving away
> from components.
ST driver is much more simpler.
And having a common dw-mipi-dsi is unreal since each HW has a different glue HW
me must handle. Even if we moved all the glue handling under
drm/bridge/synopsys,
we would need a different set of callbacks for each HW for each compatible
which is basically the actual situation except components.
Neil
>
> Thanks,
> Jagan.
>
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
On Wed, Jan 12, 2022 at 1:49 PM Neil Armstrong wrote:
>
> Hi,
>
> On 12/01/2022 08:24, Jagan Teki wrote:
> > Hi Neil,
> >
> > On Mon, Sep 7, 2020 at 1:48 PM Neil Armstrong
> > wrote:
> >>
> >> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver
> >> 1.21a), with a custom
> >> glue managing the IP resets, clock and data input similar to the DW-HDMI
> >> Glue on other
> >> Amlogic SoCs.
> >>
> >> This adds support for the Glue managing the transceiver, mimicing the init
> >> flow provided
> >> by Amlogic to setup the ENCl encoder, the glue, the transceiver, the
> >> digital D-PHY and the
> >> Analog PHY in the proper way.
> >>
> >> The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2
> >> clock, which pixel clock
> >> is derived and feeds the ENCL encoder and the VIU pixel reader.
> >>
> >> An optional "MEAS" clock can be enabled to measure the delay between each
> >> vsync feeding the
> >> DW-MIPI-DSI transceiver.
> >>
> >> Signed-off-by: Neil Armstrong
> >> ---
>
> [..]
>
> >> +
> >> +static const struct component_ops meson_dw_mipi_dsi_ops = {
> >> + .bind = meson_dw_mipi_dsi_bind,
> >> + .unbind = meson_dw_mipi_dsi_unbind,
> >> +};
> >
> > Do you thought of non-component based meson DSI like STM DSI? It
> > require changes from meson drm but just to understand if you have any
> > such plan.
>
> I have no such plans for now, note this serie has been rewritten at [1] but
> still
> with based with components.
>
> If worth it, the plan is to get it with components and than yes if it's
> simpler
> drop components completely.
Dropping components make the pipeline well suited for bridges as we
are moving bridge-driven pipelines in other areas.
>
> I'll have a look at how ST does
ST has no components. As I said above, eventually there would be
common bridge driver for dw-mipi-dsi if meson and rockchip moving away
from components.
Thanks,
Jagan.
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
Hi,
On 12/01/2022 08:24, Jagan Teki wrote:
> Hi Neil,
>
> On Mon, Sep 7, 2020 at 1:48 PM Neil Armstrong wrote:
>>
>> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a),
>> with a custom
>> glue managing the IP resets, clock and data input similar to the DW-HDMI
>> Glue on other
>> Amlogic SoCs.
>>
>> This adds support for the Glue managing the transceiver, mimicing the init
>> flow provided
>> by Amlogic to setup the ENCl encoder, the glue, the transceiver, the digital
>> D-PHY and the
>> Analog PHY in the proper way.
>>
>> The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 clock,
>> which pixel clock
>> is derived and feeds the ENCL encoder and the VIU pixel reader.
>>
>> An optional "MEAS" clock can be enabled to measure the delay between each
>> vsync feeding the
>> DW-MIPI-DSI transceiver.
>>
>> Signed-off-by: Neil Armstrong
>> ---
[..]
>> +
>> +static const struct component_ops meson_dw_mipi_dsi_ops = {
>> + .bind = meson_dw_mipi_dsi_bind,
>> + .unbind = meson_dw_mipi_dsi_unbind,
>> +};
>
> Do you thought of non-component based meson DSI like STM DSI? It
> require changes from meson drm but just to understand if you have any
> such plan.
I have no such plans for now, note this serie has been rewritten at [1] but
still
with based with components.
If worth it, the plan is to get it with components and than yes if it's simpler
drop components completely.
I'll have a look at how ST does
Neil
[1] https://lore.kernel.org/r/20220107145515.613009-1-narmstr...@baylibre.com
>
> Thanks,
> Jagan.
>
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
Hi Neil, On Mon, Sep 7, 2020 at 1:48 PM Neil Armstrong wrote: > > The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a), > with a custom > glue managing the IP resets, clock and data input similar to the DW-HDMI Glue > on other > Amlogic SoCs. > > This adds support for the Glue managing the transceiver, mimicing the init > flow provided > by Amlogic to setup the ENCl encoder, the glue, the transceiver, the digital > D-PHY and the > Analog PHY in the proper way. > > The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 clock, > which pixel clock > is derived and feeds the ENCL encoder and the VIU pixel reader. > > An optional "MEAS" clock can be enabled to measure the delay between each > vsync feeding the > DW-MIPI-DSI transceiver. > > Signed-off-by: Neil Armstrong > --- > drivers/gpu/drm/meson/Kconfig | 7 + > drivers/gpu/drm/meson/Makefile| 1 + > drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 562 ++ > 3 files changed, 570 insertions(+) > create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > > diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig > index 9f9281dd49f8..385f6f23839b 100644 > --- a/drivers/gpu/drm/meson/Kconfig > +++ b/drivers/gpu/drm/meson/Kconfig > @@ -16,3 +16,10 @@ config DRM_MESON_DW_HDMI > default y if DRM_MESON > select DRM_DW_HDMI > imply DRM_DW_HDMI_I2S_AUDIO > + > +config DRM_MESON_DW_MIPI_DSI > + tristate "MIPI DSI Synopsys Controller support for Amlogic Meson > Display" > + depends on DRM_MESON > + default y if DRM_MESON > + select DRM_DW_MIPI_DSI > + select GENERIC_PHY_MIPI_DPHY > diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile > index 28a519cdf66b..2cc870e91182 100644 > --- a/drivers/gpu/drm/meson/Makefile > +++ b/drivers/gpu/drm/meson/Makefile > @@ -5,3 +5,4 @@ meson-drm-y += meson_rdma.o meson_osd_afbcd.o > > obj-$(CONFIG_DRM_MESON) += meson-drm.o > obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o > +obj-$(CONFIG_DRM_MESON_DW_MIPI_DSI) += meson_dw_mipi_dsi.o > diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > new file mode 100644 > index ..bbe1294fce7c > --- /dev/null > +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > @@ -0,0 +1,562 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* > + * Copyright (C) 2016 BayLibre, SAS > + * Author: Neil Armstrong > + * Copyright (C) 2015 Amlogic, Inc. All rights reserved. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#include > +#include > + > +#include > +#include > +#include > +#include > + > +#include "meson_drv.h" > +#include "meson_dw_mipi_dsi.h" > +#include "meson_registers.h" > +#include "meson_venc.h" > + > +#define DRIVER_NAME "meson-dw-mipi-dsi" > +#define DRIVER_DESC "Amlogic Meson MIPI-DSI DRM driver" > + > +/* MIPI DSI/VENC Color Format Definitions */ > +#define MIPI_DSI_VENC_COLOR_30B 0x0 > +#define MIPI_DSI_VENC_COLOR_24B 0x1 > +#define MIPI_DSI_VENC_COLOR_18B 0x2 > +#define MIPI_DSI_VENC_COLOR_16B 0x3 > + > +#define COLOR_16BIT_CFG_1 0x0 > +#define COLOR_16BIT_CFG_2 0x1 > +#define COLOR_16BIT_CFG_3 0x2 > +#define COLOR_18BIT_CFG_1 0x3 > +#define COLOR_18BIT_CFG_2 0x4 > +#define COLOR_24BIT 0x5 > +#define COLOR_20BIT_LOOSE 0x6 > +#define COLOR_24_BIT_YCBCR0x7 > +#define COLOR_16BIT_YCBCR 0x8 > +#define COLOR_30BIT 0x9 > +#define COLOR_36BIT 0xa > +#define COLOR_12BIT 0xb > +#define COLOR_RGB_111 0xc > +#define COLOR_RGB_332 0xd > +#define COLOR_RGB_444 0xe > + > +/* MIPI DSI Relative REGISTERs Definitions */ > +/* For MIPI_DSI_TOP_CNTL */ > +#define BIT_DPI_COLOR_MODE20 > +#define BIT_IN_COLOR_MODE 16 > +#define BIT_CHROMA_SUBSAMPLE 14 > +#define BIT_COMP2_SEL 12 > +#define BIT_COMP1_SEL 10 > +#define BIT_COMP0_SEL 8 > +#define BIT_DE_POL 6 > +#define BIT_HSYNC_POL 5 > +#define BIT_VSYNC_POL 4 > +#define BIT_DPICOLORM 3 > +#define BIT_DPISHUTDN 2 > +#define BIT_EDPITE_INTR_PULSE 1 > +#define BIT_ERR_INTR_PULSE 0 > + > +/* HHI Registers */ > +#define HHI_VIID_CLK_DIV 0x128 /* 0x4a offset in data sheet */ > +#define VCLK2_DIV_MASK 0xff > +#define VCLK2_DIV_EN BIT(16) > +#define VCLK2_DIV_RESETBIT(17) > +#define CTS_ENCL_SEL_MASK (0xf << 12) > +#define CTS_ENCL_SEL_SHIFT 12 > +#define HHI_VIID_CLK_CNTL 0x12c /* 0x4b offset in data sheet */ > +#define VCLK2_EN BIT(19) > +#define VCLK2_SEL_MASK (0x7 << 16) > +#define VCLK2_SEL_SHIFT16 > +#define VCLK2_SOFT_RESET
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
On 07/01/2022 23:49, Martin Blumenstingl wrote:
> Hi Neil,
>
> some high-level comments from me below.
>
> On Fri, Jan 7, 2022 at 3:58 PM Neil Armstrong wrote:
> [...]
>> +/* MIPI DSI Relative REGISTERs Definitions */
>> +/* For MIPI_DSI_TOP_CNTL */
>> +#define BIT_DPI_COLOR_MODE20
>> +#define BIT_IN_COLOR_MODE 16
>> +#define BIT_CHROMA_SUBSAMPLE 14
>> +#define BIT_COMP2_SEL 12
>> +#define BIT_COMP1_SEL 10
>> +#define BIT_COMP0_SEL 8
>> +#define BIT_DE_POL 6
>> +#define BIT_HSYNC_POL 5
>> +#define BIT_VSYNC_POL 4
>> +#define BIT_DPICOLORM 3
>> +#define BIT_DPISHUTDN 2
>> +#define BIT_EDPITE_INTR_PULSE 1
>> +#define BIT_ERR_INTR_PULSE 0
> Why not use BIT() and GENMASK() for these and prefixing them with
> MIPI_DSI_TOP_CNTL_?
> That would make them consistent with other parts of the meson sub-driver.
Yeah it was a lousy copy-paste from vendor driver, and I was lazy, but I'll fix
this.
>
> [...]
>> +static void meson_dw_mipi_dsi_hw_init(struct meson_dw_mipi_dsi *mipi_dsi)
>> +{
>> + writel_relaxed((1 << 4) | (1 << 5) | (0 << 6),
>> + mipi_dsi->base + MIPI_DSI_TOP_CNTL);
> please use the macros from above
>
>> + writel_bits_relaxed(0xf, 0xf, mipi_dsi->base +
>> MIPI_DSI_TOP_SW_RESET);
>> + writel_bits_relaxed(0xf, 0, mipi_dsi->base + MIPI_DSI_TOP_SW_RESET);
>
> [...]
>> + phy_power_on(mipi_dsi->phy);
> Please propagate the error code here.
> Also shouldn't this go to a new dw_mipi_dsi_phy_power_on() as the PHY
> driver uses the updated settings from phy_configure only in it's
> .power_on callback?
Good point, let me check that.
>
> [...]
>> + phy_configure(mipi_dsi->phy, &mipi_dsi->phy_opts);
> please propagate the error code here as the PHY driver has some
> explicit code to return an error in it's .phy_configure callback
>
> [...]
>> + phy_init(mipi_dsi->phy);
> please propagate the error code here
>
> [...]
>> + phy_exit(mipi_dsi->phy);
> please propagate the error code here
ok for the 3
>
> [...]
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + mipi_dsi->base = devm_ioremap_resource(&pdev->dev, res);
> other parts of the meson DRM driver have been converted to use
> devm_platform_ioremap_resource()
> I suggest updating this as well to simplify the code here
Yep, again lazyness
>
> [...]
>> + mipi_dsi->phy = devm_phy_get(&pdev->dev, "dphy");
>> + if (IS_ERR(mipi_dsi->phy)) {
>> + ret = PTR_ERR(mipi_dsi->phy);
>> + dev_err(&pdev->dev, "failed to get mipi dphy: %d\n", ret);
>> + return ret;
> you can simplify this with:
> return dev_err_probe(&pdev->dev, PTR_ERR(mipi_dsi->phy, "failed to
> get mipi dphy\n");
>
> [...]
>> + mipi_dsi->px_clk = devm_clk_get(&pdev->dev, "px_clk");
>> + if (IS_ERR(mipi_dsi->px_clk)) {
>> + dev_err(&pdev->dev, "Unable to get PLL clk\n");
>> + return PTR_ERR(mipi_dsi->px_clk);
> you can simplify this with:
> return dev_err_probe(&pdev->dev, PTR_ERR(mipi_dsi->px_clk, "Unable
> to get PLL clk\n");
> Also should it say s/PLL clk/px clock/?
>
> [...]
>> + top_rst = devm_reset_control_get_exclusive(&pdev->dev, "top");
>> + if (IS_ERR(top_rst)) {
>> + ret = PTR_ERR(top_rst);
>> +
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(&pdev->dev, "Unable to get reset control:
>> %d\n", ret);
>> +
>> + return ret;
> you can simplify this with:
> return dev_err_probe(&pdev->dev, PTR_ERR(top_rst, "Unable to get
> reset control\n");
>
> [...]
>> + mipi_dsi->dmd = dw_mipi_dsi_probe(pdev, &mipi_dsi->pdata);
>> + if (IS_ERR(mipi_dsi->dmd)) {
>> + ret = PTR_ERR(mipi_dsi->dmd);
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(&pdev->dev,
>> + "Failed to probe dw_mipi_dsi: %d\n", ret);
> you can simplify this with:
> dev_err_probe(&pdev->dev, ret, "Failed to probe dw_mipi_dsi\n");
>
Again 4 lazyness effects, will fix !
Thanks,
Neil
>
> Best regards,
> Martin
>
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
Hi Neil,
some high-level comments from me below.
On Fri, Jan 7, 2022 at 3:58 PM Neil Armstrong wrote:
[...]
> +/* MIPI DSI Relative REGISTERs Definitions */
> +/* For MIPI_DSI_TOP_CNTL */
> +#define BIT_DPI_COLOR_MODE20
> +#define BIT_IN_COLOR_MODE 16
> +#define BIT_CHROMA_SUBSAMPLE 14
> +#define BIT_COMP2_SEL 12
> +#define BIT_COMP1_SEL 10
> +#define BIT_COMP0_SEL 8
> +#define BIT_DE_POL 6
> +#define BIT_HSYNC_POL 5
> +#define BIT_VSYNC_POL 4
> +#define BIT_DPICOLORM 3
> +#define BIT_DPISHUTDN 2
> +#define BIT_EDPITE_INTR_PULSE 1
> +#define BIT_ERR_INTR_PULSE 0
Why not use BIT() and GENMASK() for these and prefixing them with
MIPI_DSI_TOP_CNTL_?
That would make them consistent with other parts of the meson sub-driver.
[...]
> +static void meson_dw_mipi_dsi_hw_init(struct meson_dw_mipi_dsi *mipi_dsi)
> +{
> + writel_relaxed((1 << 4) | (1 << 5) | (0 << 6),
> + mipi_dsi->base + MIPI_DSI_TOP_CNTL);
please use the macros from above
> + writel_bits_relaxed(0xf, 0xf, mipi_dsi->base + MIPI_DSI_TOP_SW_RESET);
> + writel_bits_relaxed(0xf, 0, mipi_dsi->base + MIPI_DSI_TOP_SW_RESET);
[...]
> + phy_power_on(mipi_dsi->phy);
Please propagate the error code here.
Also shouldn't this go to a new dw_mipi_dsi_phy_power_on() as the PHY
driver uses the updated settings from phy_configure only in it's
.power_on callback?
[...]
> + phy_configure(mipi_dsi->phy, &mipi_dsi->phy_opts);
please propagate the error code here as the PHY driver has some
explicit code to return an error in it's .phy_configure callback
[...]
> + phy_init(mipi_dsi->phy);
please propagate the error code here
[...]
> + phy_exit(mipi_dsi->phy);
please propagate the error code here
[...]
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + mipi_dsi->base = devm_ioremap_resource(&pdev->dev, res);
other parts of the meson DRM driver have been converted to use
devm_platform_ioremap_resource()
I suggest updating this as well to simplify the code here
[...]
> + mipi_dsi->phy = devm_phy_get(&pdev->dev, "dphy");
> + if (IS_ERR(mipi_dsi->phy)) {
> + ret = PTR_ERR(mipi_dsi->phy);
> + dev_err(&pdev->dev, "failed to get mipi dphy: %d\n", ret);
> + return ret;
you can simplify this with:
return dev_err_probe(&pdev->dev, PTR_ERR(mipi_dsi->phy, "failed to
get mipi dphy\n");
[...]
> + mipi_dsi->px_clk = devm_clk_get(&pdev->dev, "px_clk");
> + if (IS_ERR(mipi_dsi->px_clk)) {
> + dev_err(&pdev->dev, "Unable to get PLL clk\n");
> + return PTR_ERR(mipi_dsi->px_clk);
you can simplify this with:
return dev_err_probe(&pdev->dev, PTR_ERR(mipi_dsi->px_clk, "Unable
to get PLL clk\n");
Also should it say s/PLL clk/px clock/?
[...]
> + top_rst = devm_reset_control_get_exclusive(&pdev->dev, "top");
> + if (IS_ERR(top_rst)) {
> + ret = PTR_ERR(top_rst);
> +
> + if (ret != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Unable to get reset control:
> %d\n", ret);
> +
> + return ret;
you can simplify this with:
return dev_err_probe(&pdev->dev, PTR_ERR(top_rst, "Unable to get
reset control\n");
[...]
> + mipi_dsi->dmd = dw_mipi_dsi_probe(pdev, &mipi_dsi->pdata);
> + if (IS_ERR(mipi_dsi->dmd)) {
> + ret = PTR_ERR(mipi_dsi->dmd);
> + if (ret != -EPROBE_DEFER)
> + dev_err(&pdev->dev,
> + "Failed to probe dw_mipi_dsi: %d\n", ret);
you can simplify this with:
dev_err_probe(&pdev->dev, ret, "Failed to probe dw_mipi_dsi\n");
Best regards,
Martin
[PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
The Amlogic G12A/G12B/SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver
1.21a),
with a custom glue managing the IP resets, clock and data input similar to the
DW-HDMI
Glue on other Amlogic SoCs.
This adds support for the Glue managing the transceiver, mimicing the init flow
provided
by Amlogic to setup the ENCL encoder, the glue, the transceiver, the digital
D-PHY and the
Analog PHY in the proper way.
An optional "MEAS" clock can be enabled to measure the delay between each vsync
feeding the
DW-MIPI-DSI transceiver.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/Kconfig | 7 +
drivers/gpu/drm/meson/Makefile| 1 +
drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 383 ++
drivers/gpu/drm/meson/meson_dw_mipi_dsi.h | 115 +++
4 files changed, 506 insertions(+)
create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.h
diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig
index 6c70fc3214af..71a1364b51e1 100644
--- a/drivers/gpu/drm/meson/Kconfig
+++ b/drivers/gpu/drm/meson/Kconfig
@@ -17,3 +17,10 @@ config DRM_MESON_DW_HDMI
default y if DRM_MESON
select DRM_DW_HDMI
imply DRM_DW_HDMI_I2S_AUDIO
+
+config DRM_MESON_DW_MIPI_DSI
+ tristate "MIPI DSI Synopsys Controller support for Amlogic Meson
Display"
+ depends on DRM_MESON
+ default y if DRM_MESON
+ select DRM_DW_MIPI_DSI
+ select GENERIC_PHY_MIPI_DPHY
diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile
index 833e18c20603..43071bdbd4b9 100644
--- a/drivers/gpu/drm/meson/Makefile
+++ b/drivers/gpu/drm/meson/Makefile
@@ -6,3 +6,4 @@ meson-drm-y += meson_encoder_hdmi.o meson_encoder_dsi.o
obj-$(CONFIG_DRM_MESON) += meson-drm.o
obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o
+obj-$(CONFIG_DRM_MESON_DW_MIPI_DSI) += meson_dw_mipi_dsi.o
diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
new file mode 100644
index ..75af3eec1b74
--- /dev/null
+++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
@@ -0,0 +1,383 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2021 BayLibre, SAS
+ * Author: Neil Armstrong
+ * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "meson_drv.h"
+#include "meson_dw_mipi_dsi.h"
+#include "meson_registers.h"
+#include "meson_venc.h"
+
+#define DRIVER_NAME "meson-dw-mipi-dsi"
+#define DRIVER_DESC "Amlogic Meson MIPI-DSI DRM driver"
+
+/* MIPI DSI/VENC Color Format Definitions */
+#define MIPI_DSI_VENC_COLOR_30B 0x0
+#define MIPI_DSI_VENC_COLOR_24B 0x1
+#define MIPI_DSI_VENC_COLOR_18B 0x2
+#define MIPI_DSI_VENC_COLOR_16B 0x3
+
+#define COLOR_16BIT_CFG_1 0x0
+#define COLOR_16BIT_CFG_2 0x1
+#define COLOR_16BIT_CFG_3 0x2
+#define COLOR_18BIT_CFG_1 0x3
+#define COLOR_18BIT_CFG_2 0x4
+#define COLOR_24BIT 0x5
+#define COLOR_20BIT_LOOSE 0x6
+#define COLOR_24_BIT_YCBCR0x7
+#define COLOR_16BIT_YCBCR 0x8
+#define COLOR_30BIT 0x9
+#define COLOR_36BIT 0xa
+#define COLOR_12BIT 0xb
+#define COLOR_RGB_111 0xc
+#define COLOR_RGB_332 0xd
+#define COLOR_RGB_444 0xe
+
+/* MIPI DSI Relative REGISTERs Definitions */
+/* For MIPI_DSI_TOP_CNTL */
+#define BIT_DPI_COLOR_MODE20
+#define BIT_IN_COLOR_MODE 16
+#define BIT_CHROMA_SUBSAMPLE 14
+#define BIT_COMP2_SEL 12
+#define BIT_COMP1_SEL 10
+#define BIT_COMP0_SEL 8
+#define BIT_DE_POL 6
+#define BIT_HSYNC_POL 5
+#define BIT_VSYNC_POL 4
+#define BIT_DPICOLORM 3
+#define BIT_DPISHUTDN 2
+#define BIT_EDPITE_INTR_PULSE 1
+#define BIT_ERR_INTR_PULSE 0
+
+struct meson_dw_mipi_dsi {
+ struct meson_drm *priv;
+ struct device *dev;
+ void __iomem *base;
+ struct phy *phy;
+ union phy_configure_opts phy_opts;
+ struct dw_mipi_dsi *dmd;
+ struct dw_mipi_dsi_plat_data pdata;
+ struct mipi_dsi_device *dsi_device;
+ const struct drm_display_mode *mode;
+ struct clk *px_clk;
+};
+
+#define encoder_to_meson_dw_mipi_dsi(x) \
+ container_of(x, struct meson_dw_mipi_dsi, encoder)
+
+static void meson_dw_mipi_dsi_hw_init(struct meson_dw_mipi_dsi *mipi_dsi)
+{
+ writel_relaxed((1 << 4) | (1 << 5) | (0 << 6),
+ mipi_dsi->base + MIPI_DSI_TOP_CNTL);
+
+ writel_bits_relaxed(0xf, 0xf, mipi_dsi->base + MIPI_DSI_TOP_SW_RESET);
+ writel_bits_relaxed(0xf, 0, mipi_dsi->base + MIPI_DSI_TOP_SW_RESET);
+
+ writel_bits_relaxed(0x3, 0x3, mipi_ds
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
On Thu, Sep 17, 2020 at 09:14:33AM +0200, Neil Armstrong wrote: > On 08/09/2020 10:46, Daniel Vetter wrote: > > On Tue, Sep 08, 2020 at 10:06:03AM +0200, Neil Armstrong wrote: > >> Hi, > >> > >> On 07/09/2020 20:03, Daniel Vetter wrote: > >>> On Mon, Sep 07, 2020 at 11:03:29AM +0200, Neil Armstrong wrote: > On 07/09/2020 10:44, Daniel Vetter wrote: > > On Mon, Sep 07, 2020 at 10:43:51AM +0200, Daniel Vetter wrote: > >> On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote: > >>> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver > >>> 1.21a), with a custom > >>> glue managing the IP resets, clock and data input similar to the > >>> DW-HDMI Glue on other > >>> Amlogic SoCs. > >>> > >>> This adds support for the Glue managing the transceiver, mimicing the > >>> init flow provided > >>> by Amlogic to setup the ENCl encoder, the glue, the transceiver, the > >>> digital D-PHY and the > >>> Analog PHY in the proper way. > >>> > >>> The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 > >>> clock, which pixel clock > >>> is derived and feeds the ENCL encoder and the VIU pixel reader. > >>> > >>> An optional "MEAS" clock can be enabled to measure the delay between > >>> each vsync feeding the > >>> DW-MIPI-DSI transceiver. > >>> > >>> Signed-off-by: Neil Armstrong > >> > >> More dw-hdmi drivers which aren't bridges but components, and the > >> thing is > >> still midlayer-y as heck :-/ > > > > *dw-dsi, but really they both work the same way and should both be fixed > > ... > > They are bridges but since they have platform-dependent code due to > theirs's generic IP > nature, they need to be intanciated by components to sync with the > platform code. > >>> > >>> Yeah that's how it currently works, but there's not much reason why it > >>> needs to work like that. That platform glue code can also be put behind > >>> the drm_bridge abstraction, and we could use the normal dt based bridge > >>> lookup like for everything else. > >>> > >>> Afaiui the only reason dw-* bridge drivers work like that is because for > >>> historical reasons we only had component.c at first, and none of the more > >>> fancy dynamic bridge lookup. So would be really good to switch this all > >>> over to a proper&clean bridge abstraction, and not leak everything around. > >> > >> Does it mean we should avoit using components, right ? > > > > Yup, at least when there's an established specific mechanism to handle > > cross-driver interactions/EPROBE_DEFER. > > > > So if you want a drm_panel or drm_bridge or a clock or i2c or anything > > else standardized like that, no component.c please. That's just for the > > driver-specific glue when you have entirely IP-specific way of building up > > a driver from components, which will never be reused outside of that > > overall driver. > > > > Hence why dw-* using components is rather uncool. > > > >>> I've typed up what I think should be the way forward a few times already, > >>> but thus far not even the todo.rst entry materialized: > >>> > >>> https://lore.kernel.org/dri-devel/20200430135841.GE10381@phenom.ffwll.local/ > >>> > >>> If everyone is always about "not in my patch series" it'll never happen. > >> > >> Today, the dw-mipi-dsi and dw-mipi-hdmi has mandatory callbacks to > >> implement > >> vendor specific features, like : > >> - hdmi/dsi phy handling when mixed into the glue/custom/synopsys but with > >> platform specific values > >> - platform specific mode validation > >> - hpd setup => could use laurent's work here with no_connector, but how do > >> we handle rxsense ??? > >> - dsi timings/lane mbps ? these are platform phy specific > >> > >> For amlogic, I can split the "component" code handling venc/vclk into a > >> primary bridge and add a > >> secondary driver only handling the glue around dw-mipi-dsi/dw-mipi-hdmi, > >> would that be a good start ? > > > > I think what we should do here: > > > > - type up todo.rst with the overall structure we want to aim for, i.e. > > where is the code, who sets up what, how are the bridges bound into the > > overall driver. > > OK, sure, this can be a good start, but first I would like all the other > bridge > maintainers & reviewers to agree on the the wanted structure. > > > > > - demidlayer dw-* enough so that the callbacks are gone, and it becomes > > more a toolbox/library for building a dw-* driver. Maybe we're there > > already. > > This is not really wanted, otherwise we would duplicate a large amount of code > over all the platform glues, is this really wanted ? > > Today, they already are a toolbox, with different levels of callback neded > depending on how deep the integration is. Yeah I guess getting rid of all of them doesn't make that much sense. > > - All new drivers then need to use the toolbox and have everyt
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
On 08/09/2020 10:46, Daniel Vetter wrote: > On Tue, Sep 08, 2020 at 10:06:03AM +0200, Neil Armstrong wrote: >> Hi, >> >> On 07/09/2020 20:03, Daniel Vetter wrote: >>> On Mon, Sep 07, 2020 at 11:03:29AM +0200, Neil Armstrong wrote: On 07/09/2020 10:44, Daniel Vetter wrote: > On Mon, Sep 07, 2020 at 10:43:51AM +0200, Daniel Vetter wrote: >> On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote: >>> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver >>> 1.21a), with a custom >>> glue managing the IP resets, clock and data input similar to the >>> DW-HDMI Glue on other >>> Amlogic SoCs. >>> >>> This adds support for the Glue managing the transceiver, mimicing the >>> init flow provided >>> by Amlogic to setup the ENCl encoder, the glue, the transceiver, the >>> digital D-PHY and the >>> Analog PHY in the proper way. >>> >>> The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 >>> clock, which pixel clock >>> is derived and feeds the ENCL encoder and the VIU pixel reader. >>> >>> An optional "MEAS" clock can be enabled to measure the delay between >>> each vsync feeding the >>> DW-MIPI-DSI transceiver. >>> >>> Signed-off-by: Neil Armstrong >> >> More dw-hdmi drivers which aren't bridges but components, and the thing >> is >> still midlayer-y as heck :-/ > > *dw-dsi, but really they both work the same way and should both be fixed > ... They are bridges but since they have platform-dependent code due to theirs's generic IP nature, they need to be intanciated by components to sync with the platform code. >>> >>> Yeah that's how it currently works, but there's not much reason why it >>> needs to work like that. That platform glue code can also be put behind >>> the drm_bridge abstraction, and we could use the normal dt based bridge >>> lookup like for everything else. >>> >>> Afaiui the only reason dw-* bridge drivers work like that is because for >>> historical reasons we only had component.c at first, and none of the more >>> fancy dynamic bridge lookup. So would be really good to switch this all >>> over to a proper&clean bridge abstraction, and not leak everything around. >> >> Does it mean we should avoit using components, right ? > > Yup, at least when there's an established specific mechanism to handle > cross-driver interactions/EPROBE_DEFER. > > So if you want a drm_panel or drm_bridge or a clock or i2c or anything > else standardized like that, no component.c please. That's just for the > driver-specific glue when you have entirely IP-specific way of building up > a driver from components, which will never be reused outside of that > overall driver. > > Hence why dw-* using components is rather uncool. > >>> I've typed up what I think should be the way forward a few times already, >>> but thus far not even the todo.rst entry materialized: >>> >>> https://lore.kernel.org/dri-devel/20200430135841.GE10381@phenom.ffwll.local/ >>> >>> If everyone is always about "not in my patch series" it'll never happen. >> >> Today, the dw-mipi-dsi and dw-mipi-hdmi has mandatory callbacks to implement >> vendor specific features, like : >> - hdmi/dsi phy handling when mixed into the glue/custom/synopsys but with >> platform specific values >> - platform specific mode validation >> - hpd setup => could use laurent's work here with no_connector, but how do >> we handle rxsense ??? >> - dsi timings/lane mbps ? these are platform phy specific >> >> For amlogic, I can split the "component" code handling venc/vclk into a >> primary bridge and add a >> secondary driver only handling the glue around dw-mipi-dsi/dw-mipi-hdmi, >> would that be a good start ? > > I think what we should do here: > > - type up todo.rst with the overall structure we want to aim for, i.e. > where is the code, who sets up what, how are the bridges bound into the > overall driver. OK, sure, this can be a good start, but first I would like all the other bridge maintainers & reviewers to agree on the the wanted structure. > > - demidlayer dw-* enough so that the callbacks are gone, and it becomes > more a toolbox/library for building a dw-* driver. Maybe we're there > already. This is not really wanted, otherwise we would duplicate a large amount of code over all the platform glues, is this really wanted ? Today, they already are a toolbox, with different levels of callback neded depending on how deep the integration is. > > - All new drivers then need to use the toolbox and have everything behind > a drm_bridge driver in drm/bridge/, with just default binding exposed to > drivers, no EXPORT_SYMBOL at all. Also no exported symbols used, this > should all be directly linked into the dw-*.ko imo and treated as > internals. In theory this is cool, in practice, this is impossible for meson_dw_hdmi, the first reason is how the reg
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
On Tue, Sep 08, 2020 at 10:06:03AM +0200, Neil Armstrong wrote: > Hi, > > On 07/09/2020 20:03, Daniel Vetter wrote: > > On Mon, Sep 07, 2020 at 11:03:29AM +0200, Neil Armstrong wrote: > >> On 07/09/2020 10:44, Daniel Vetter wrote: > >>> On Mon, Sep 07, 2020 at 10:43:51AM +0200, Daniel Vetter wrote: > On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote: > > The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver > > 1.21a), with a custom > > glue managing the IP resets, clock and data input similar to the > > DW-HDMI Glue on other > > Amlogic SoCs. > > > > This adds support for the Glue managing the transceiver, mimicing the > > init flow provided > > by Amlogic to setup the ENCl encoder, the glue, the transceiver, the > > digital D-PHY and the > > Analog PHY in the proper way. > > > > The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 > > clock, which pixel clock > > is derived and feeds the ENCL encoder and the VIU pixel reader. > > > > An optional "MEAS" clock can be enabled to measure the delay between > > each vsync feeding the > > DW-MIPI-DSI transceiver. > > > > Signed-off-by: Neil Armstrong > > More dw-hdmi drivers which aren't bridges but components, and the thing > is > still midlayer-y as heck :-/ > >>> > >>> *dw-dsi, but really they both work the same way and should both be fixed > >>> ... > >> > >> They are bridges but since they have platform-dependent code due to > >> theirs's generic IP > >> nature, they need to be intanciated by components to sync with the > >> platform code. > > > > Yeah that's how it currently works, but there's not much reason why it > > needs to work like that. That platform glue code can also be put behind > > the drm_bridge abstraction, and we could use the normal dt based bridge > > lookup like for everything else. > > > > Afaiui the only reason dw-* bridge drivers work like that is because for > > historical reasons we only had component.c at first, and none of the more > > fancy dynamic bridge lookup. So would be really good to switch this all > > over to a proper&clean bridge abstraction, and not leak everything around. > > Does it mean we should avoit using components, right ? Yup, at least when there's an established specific mechanism to handle cross-driver interactions/EPROBE_DEFER. So if you want a drm_panel or drm_bridge or a clock or i2c or anything else standardized like that, no component.c please. That's just for the driver-specific glue when you have entirely IP-specific way of building up a driver from components, which will never be reused outside of that overall driver. Hence why dw-* using components is rather uncool. > > I've typed up what I think should be the way forward a few times already, > > but thus far not even the todo.rst entry materialized: > > > > https://lore.kernel.org/dri-devel/20200430135841.GE10381@phenom.ffwll.local/ > > > > If everyone is always about "not in my patch series" it'll never happen. > > Today, the dw-mipi-dsi and dw-mipi-hdmi has mandatory callbacks to implement > vendor specific features, like : > - hdmi/dsi phy handling when mixed into the glue/custom/synopsys but with > platform specific values > - platform specific mode validation > - hpd setup => could use laurent's work here with no_connector, but how do we > handle rxsense ??? > - dsi timings/lane mbps ? these are platform phy specific > > For amlogic, I can split the "component" code handling venc/vclk into a > primary bridge and add a > secondary driver only handling the glue around dw-mipi-dsi/dw-mipi-hdmi, > would that be a good start ? I think what we should do here: - type up todo.rst with the overall structure we want to aim for, i.e. where is the code, who sets up what, how are the bridges bound into the overall driver. - demidlayer dw-* enough so that the callbacks are gone, and it becomes more a toolbox/library for building a dw-* driver. Maybe we're there already. - All new drivers then need to use the toolbox and have everything behind a drm_bridge driver in drm/bridge/, with just default binding exposed to drivers, no EXPORT_SYMBOL at all. Also no exported symbols used, this should all be directly linked into the dw-*.ko imo and treated as internals. - We might need to split the header files to make that clean enough. - Once all existing dw-* users are converted, we ditch the EXPORT_SYMBOL stuff completely (since I expect we'll just have one overall dw-dsi.ko module with all bridge driver variants). Cheers, Daniel > > Neil > > > > > Cheers, Daniel > > > > > >> > >> Neil > >> > >>> > > Can we try to fix this? There's a ton of this going on, and the more we > add the old fashioned way the harder this gets to fix up for real. > -Daniel > > > --- > > drivers/gpu/drm/meson/Kconfig | 7 + > >
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
Hi, On 07/09/2020 20:03, Daniel Vetter wrote: > On Mon, Sep 07, 2020 at 11:03:29AM +0200, Neil Armstrong wrote: >> On 07/09/2020 10:44, Daniel Vetter wrote: >>> On Mon, Sep 07, 2020 at 10:43:51AM +0200, Daniel Vetter wrote: On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote: > The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver > 1.21a), with a custom > glue managing the IP resets, clock and data input similar to the DW-HDMI > Glue on other > Amlogic SoCs. > > This adds support for the Glue managing the transceiver, mimicing the > init flow provided > by Amlogic to setup the ENCl encoder, the glue, the transceiver, the > digital D-PHY and the > Analog PHY in the proper way. > > The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 > clock, which pixel clock > is derived and feeds the ENCL encoder and the VIU pixel reader. > > An optional "MEAS" clock can be enabled to measure the delay between each > vsync feeding the > DW-MIPI-DSI transceiver. > > Signed-off-by: Neil Armstrong More dw-hdmi drivers which aren't bridges but components, and the thing is still midlayer-y as heck :-/ >>> >>> *dw-dsi, but really they both work the same way and should both be fixed >>> ... >> >> They are bridges but since they have platform-dependent code due to theirs's >> generic IP >> nature, they need to be intanciated by components to sync with the platform >> code. > > Yeah that's how it currently works, but there's not much reason why it > needs to work like that. That platform glue code can also be put behind > the drm_bridge abstraction, and we could use the normal dt based bridge > lookup like for everything else. > > Afaiui the only reason dw-* bridge drivers work like that is because for > historical reasons we only had component.c at first, and none of the more > fancy dynamic bridge lookup. So would be really good to switch this all > over to a proper&clean bridge abstraction, and not leak everything around. Does it mean we should avoit using components, right ? > > I've typed up what I think should be the way forward a few times already, > but thus far not even the todo.rst entry materialized: > > https://lore.kernel.org/dri-devel/20200430135841.GE10381@phenom.ffwll.local/ > > If everyone is always about "not in my patch series" it'll never happen. Today, the dw-mipi-dsi and dw-mipi-hdmi has mandatory callbacks to implement vendor specific features, like : - hdmi/dsi phy handling when mixed into the glue/custom/synopsys but with platform specific values - platform specific mode validation - hpd setup => could use laurent's work here with no_connector, but how do we handle rxsense ??? - dsi timings/lane mbps ? these are platform phy specific For amlogic, I can split the "component" code handling venc/vclk into a primary bridge and add a secondary driver only handling the glue around dw-mipi-dsi/dw-mipi-hdmi, would that be a good start ? Neil > > Cheers, Daniel > > >> >> Neil >> >>> Can we try to fix this? There's a ton of this going on, and the more we add the old fashioned way the harder this gets to fix up for real. -Daniel > --- > drivers/gpu/drm/meson/Kconfig | 7 + > drivers/gpu/drm/meson/Makefile| 1 + > drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 562 ++ > 3 files changed, 570 insertions(+) > create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > > diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig > index 9f9281dd49f8..385f6f23839b 100644 > --- a/drivers/gpu/drm/meson/Kconfig > +++ b/drivers/gpu/drm/meson/Kconfig > @@ -16,3 +16,10 @@ config DRM_MESON_DW_HDMI > default y if DRM_MESON > select DRM_DW_HDMI > imply DRM_DW_HDMI_I2S_AUDIO > + > +config DRM_MESON_DW_MIPI_DSI > + tristate "MIPI DSI Synopsys Controller support for Amlogic Meson > Display" > + depends on DRM_MESON > + default y if DRM_MESON > + select DRM_DW_MIPI_DSI > + select GENERIC_PHY_MIPI_DPHY > diff --git a/drivers/gpu/drm/meson/Makefile > b/drivers/gpu/drm/meson/Makefile > index 28a519cdf66b..2cc870e91182 100644 > --- a/drivers/gpu/drm/meson/Makefile > +++ b/drivers/gpu/drm/meson/Makefile > @@ -5,3 +5,4 @@ meson-drm-y += meson_rdma.o meson_osd_afbcd.o > > obj-$(CONFIG_DRM_MESON) += meson-drm.o > obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o > +obj-$(CONFIG_DRM_MESON_DW_MIPI_DSI) += meson_dw_mipi_dsi.o > diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > new file mode 100644 > index ..bbe1294fce7c > --- /dev/null > +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > @@ -0,0 +1,562 @@ > +// SPDX-License-Identifier: GPL-2.0-or-l
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
On Mon, Sep 07, 2020 at 11:03:29AM +0200, Neil Armstrong wrote: > On 07/09/2020 10:44, Daniel Vetter wrote: > > On Mon, Sep 07, 2020 at 10:43:51AM +0200, Daniel Vetter wrote: > >> On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote: > >>> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver > >>> 1.21a), with a custom > >>> glue managing the IP resets, clock and data input similar to the DW-HDMI > >>> Glue on other > >>> Amlogic SoCs. > >>> > >>> This adds support for the Glue managing the transceiver, mimicing the > >>> init flow provided > >>> by Amlogic to setup the ENCl encoder, the glue, the transceiver, the > >>> digital D-PHY and the > >>> Analog PHY in the proper way. > >>> > >>> The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 > >>> clock, which pixel clock > >>> is derived and feeds the ENCL encoder and the VIU pixel reader. > >>> > >>> An optional "MEAS" clock can be enabled to measure the delay between each > >>> vsync feeding the > >>> DW-MIPI-DSI transceiver. > >>> > >>> Signed-off-by: Neil Armstrong > >> > >> More dw-hdmi drivers which aren't bridges but components, and the thing is > >> still midlayer-y as heck :-/ > > > > *dw-dsi, but really they both work the same way and should both be fixed > > ... > > They are bridges but since they have platform-dependent code due to theirs's > generic IP > nature, they need to be intanciated by components to sync with the platform > code. Yeah that's how it currently works, but there's not much reason why it needs to work like that. That platform glue code can also be put behind the drm_bridge abstraction, and we could use the normal dt based bridge lookup like for everything else. Afaiui the only reason dw-* bridge drivers work like that is because for historical reasons we only had component.c at first, and none of the more fancy dynamic bridge lookup. So would be really good to switch this all over to a proper&clean bridge abstraction, and not leak everything around. I've typed up what I think should be the way forward a few times already, but thus far not even the todo.rst entry materialized: https://lore.kernel.org/dri-devel/20200430135841.GE10381@phenom.ffwll.local/ If everyone is always about "not in my patch series" it'll never happen. Cheers, Daniel > > Neil > > > > >> > >> Can we try to fix this? There's a ton of this going on, and the more we > >> add the old fashioned way the harder this gets to fix up for real. > >> -Daniel > >> > >>> --- > >>> drivers/gpu/drm/meson/Kconfig | 7 + > >>> drivers/gpu/drm/meson/Makefile| 1 + > >>> drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 562 ++ > >>> 3 files changed, 570 insertions(+) > >>> create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > >>> > >>> diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig > >>> index 9f9281dd49f8..385f6f23839b 100644 > >>> --- a/drivers/gpu/drm/meson/Kconfig > >>> +++ b/drivers/gpu/drm/meson/Kconfig > >>> @@ -16,3 +16,10 @@ config DRM_MESON_DW_HDMI > >>> default y if DRM_MESON > >>> select DRM_DW_HDMI > >>> imply DRM_DW_HDMI_I2S_AUDIO > >>> + > >>> +config DRM_MESON_DW_MIPI_DSI > >>> + tristate "MIPI DSI Synopsys Controller support for Amlogic Meson > >>> Display" > >>> + depends on DRM_MESON > >>> + default y if DRM_MESON > >>> + select DRM_DW_MIPI_DSI > >>> + select GENERIC_PHY_MIPI_DPHY > >>> diff --git a/drivers/gpu/drm/meson/Makefile > >>> b/drivers/gpu/drm/meson/Makefile > >>> index 28a519cdf66b..2cc870e91182 100644 > >>> --- a/drivers/gpu/drm/meson/Makefile > >>> +++ b/drivers/gpu/drm/meson/Makefile > >>> @@ -5,3 +5,4 @@ meson-drm-y += meson_rdma.o meson_osd_afbcd.o > >>> > >>> obj-$(CONFIG_DRM_MESON) += meson-drm.o > >>> obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o > >>> +obj-$(CONFIG_DRM_MESON_DW_MIPI_DSI) += meson_dw_mipi_dsi.o > >>> diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > >>> b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > >>> new file mode 100644 > >>> index ..bbe1294fce7c > >>> --- /dev/null > >>> +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > >>> @@ -0,0 +1,562 @@ > >>> +// SPDX-License-Identifier: GPL-2.0-or-later > >>> +/* > >>> + * Copyright (C) 2016 BayLibre, SAS > >>> + * Author: Neil Armstrong > >>> + * Copyright (C) 2015 Amlogic, Inc. All rights reserved. > >>> + */ > >>> + > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> + > >>> +#include > >>> + > >>> +#include > >>> +#include > >>> + > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> + > >>> +#include "meson_drv.h" > >>> +#include "meson_dw_mipi_dsi.h" > >>> +#include "meson_registers.h" > >>> +#include "meson_venc.h" > >>> + > >>> +#define DRIVER_NAME "meson-dw-mipi-dsi" > >>> +#define DRIVER_DESC "Amlogic Meson MIPI-DSI DRM driver" > >>> + > >>> +/* MIPI DSI/VENC Color Format Def
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
On 07/09/2020 10:44, Daniel Vetter wrote: > On Mon, Sep 07, 2020 at 10:43:51AM +0200, Daniel Vetter wrote: >> On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote: >>> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a), >>> with a custom >>> glue managing the IP resets, clock and data input similar to the DW-HDMI >>> Glue on other >>> Amlogic SoCs. >>> >>> This adds support for the Glue managing the transceiver, mimicing the init >>> flow provided >>> by Amlogic to setup the ENCl encoder, the glue, the transceiver, the >>> digital D-PHY and the >>> Analog PHY in the proper way. >>> >>> The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 >>> clock, which pixel clock >>> is derived and feeds the ENCL encoder and the VIU pixel reader. >>> >>> An optional "MEAS" clock can be enabled to measure the delay between each >>> vsync feeding the >>> DW-MIPI-DSI transceiver. >>> >>> Signed-off-by: Neil Armstrong >> >> More dw-hdmi drivers which aren't bridges but components, and the thing is >> still midlayer-y as heck :-/ > > *dw-dsi, but really they both work the same way and should both be fixed > ... They are bridges but since they have platform-dependent code due to theirs's generic IP nature, they need to be intanciated by components to sync with the platform code. Neil > >> >> Can we try to fix this? There's a ton of this going on, and the more we >> add the old fashioned way the harder this gets to fix up for real. >> -Daniel >> >>> --- >>> drivers/gpu/drm/meson/Kconfig | 7 + >>> drivers/gpu/drm/meson/Makefile| 1 + >>> drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 562 ++ >>> 3 files changed, 570 insertions(+) >>> create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c >>> >>> diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig >>> index 9f9281dd49f8..385f6f23839b 100644 >>> --- a/drivers/gpu/drm/meson/Kconfig >>> +++ b/drivers/gpu/drm/meson/Kconfig >>> @@ -16,3 +16,10 @@ config DRM_MESON_DW_HDMI >>> default y if DRM_MESON >>> select DRM_DW_HDMI >>> imply DRM_DW_HDMI_I2S_AUDIO >>> + >>> +config DRM_MESON_DW_MIPI_DSI >>> + tristate "MIPI DSI Synopsys Controller support for Amlogic Meson >>> Display" >>> + depends on DRM_MESON >>> + default y if DRM_MESON >>> + select DRM_DW_MIPI_DSI >>> + select GENERIC_PHY_MIPI_DPHY >>> diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile >>> index 28a519cdf66b..2cc870e91182 100644 >>> --- a/drivers/gpu/drm/meson/Makefile >>> +++ b/drivers/gpu/drm/meson/Makefile >>> @@ -5,3 +5,4 @@ meson-drm-y += meson_rdma.o meson_osd_afbcd.o >>> >>> obj-$(CONFIG_DRM_MESON) += meson-drm.o >>> obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o >>> +obj-$(CONFIG_DRM_MESON_DW_MIPI_DSI) += meson_dw_mipi_dsi.o >>> diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c >>> b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c >>> new file mode 100644 >>> index ..bbe1294fce7c >>> --- /dev/null >>> +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c >>> @@ -0,0 +1,562 @@ >>> +// SPDX-License-Identifier: GPL-2.0-or-later >>> +/* >>> + * Copyright (C) 2016 BayLibre, SAS >>> + * Author: Neil Armstrong >>> + * Copyright (C) 2015 Amlogic, Inc. All rights reserved. >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include >>> + >>> +#include >>> +#include >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include "meson_drv.h" >>> +#include "meson_dw_mipi_dsi.h" >>> +#include "meson_registers.h" >>> +#include "meson_venc.h" >>> + >>> +#define DRIVER_NAME "meson-dw-mipi-dsi" >>> +#define DRIVER_DESC "Amlogic Meson MIPI-DSI DRM driver" >>> + >>> +/* MIPI DSI/VENC Color Format Definitions */ >>> +#define MIPI_DSI_VENC_COLOR_30B 0x0 >>> +#define MIPI_DSI_VENC_COLOR_24B 0x1 >>> +#define MIPI_DSI_VENC_COLOR_18B 0x2 >>> +#define MIPI_DSI_VENC_COLOR_16B 0x3 >>> + >>> +#define COLOR_16BIT_CFG_1 0x0 >>> +#define COLOR_16BIT_CFG_2 0x1 >>> +#define COLOR_16BIT_CFG_3 0x2 >>> +#define COLOR_18BIT_CFG_1 0x3 >>> +#define COLOR_18BIT_CFG_2 0x4 >>> +#define COLOR_24BIT 0x5 >>> +#define COLOR_20BIT_LOOSE 0x6 >>> +#define COLOR_24_BIT_YCBCR0x7 >>> +#define COLOR_16BIT_YCBCR 0x8 >>> +#define COLOR_30BIT 0x9 >>> +#define COLOR_36BIT 0xa >>> +#define COLOR_12BIT 0xb >>> +#define COLOR_RGB_111 0xc >>> +#define COLOR_RGB_332 0xd >>> +#define COLOR_RGB_444 0xe >>> + >>> +/* MIPI DSI Relative REGISTERs Definitions */ >>> +/* For MIPI_DSI_TOP_CNTL */ >>> +#define BIT_DPI_COLOR_MODE20 >>> +#define BIT_IN_COLOR_MODE 16 >>> +#define BIT_CHROMA_SUBSAMPLE 14 >>> +#define BIT_COMP2_SEL 12 >>> +#define BIT_COMP1_SEL 10
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
On Mon, Sep 07, 2020 at 10:43:51AM +0200, Daniel Vetter wrote: > On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote: > > The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a), > > with a custom > > glue managing the IP resets, clock and data input similar to the DW-HDMI > > Glue on other > > Amlogic SoCs. > > > > This adds support for the Glue managing the transceiver, mimicing the init > > flow provided > > by Amlogic to setup the ENCl encoder, the glue, the transceiver, the > > digital D-PHY and the > > Analog PHY in the proper way. > > > > The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 > > clock, which pixel clock > > is derived and feeds the ENCL encoder and the VIU pixel reader. > > > > An optional "MEAS" clock can be enabled to measure the delay between each > > vsync feeding the > > DW-MIPI-DSI transceiver. > > > > Signed-off-by: Neil Armstrong > > More dw-hdmi drivers which aren't bridges but components, and the thing is > still midlayer-y as heck :-/ *dw-dsi, but really they both work the same way and should both be fixed ... > > Can we try to fix this? There's a ton of this going on, and the more we > add the old fashioned way the harder this gets to fix up for real. > -Daniel > > > --- > > drivers/gpu/drm/meson/Kconfig | 7 + > > drivers/gpu/drm/meson/Makefile| 1 + > > drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 562 ++ > > 3 files changed, 570 insertions(+) > > create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > > > > diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig > > index 9f9281dd49f8..385f6f23839b 100644 > > --- a/drivers/gpu/drm/meson/Kconfig > > +++ b/drivers/gpu/drm/meson/Kconfig > > @@ -16,3 +16,10 @@ config DRM_MESON_DW_HDMI > > default y if DRM_MESON > > select DRM_DW_HDMI > > imply DRM_DW_HDMI_I2S_AUDIO > > + > > +config DRM_MESON_DW_MIPI_DSI > > + tristate "MIPI DSI Synopsys Controller support for Amlogic Meson > > Display" > > + depends on DRM_MESON > > + default y if DRM_MESON > > + select DRM_DW_MIPI_DSI > > + select GENERIC_PHY_MIPI_DPHY > > diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile > > index 28a519cdf66b..2cc870e91182 100644 > > --- a/drivers/gpu/drm/meson/Makefile > > +++ b/drivers/gpu/drm/meson/Makefile > > @@ -5,3 +5,4 @@ meson-drm-y += meson_rdma.o meson_osd_afbcd.o > > > > obj-$(CONFIG_DRM_MESON) += meson-drm.o > > obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o > > +obj-$(CONFIG_DRM_MESON_DW_MIPI_DSI) += meson_dw_mipi_dsi.o > > diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > > b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > > new file mode 100644 > > index ..bbe1294fce7c > > --- /dev/null > > +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > > @@ -0,0 +1,562 @@ > > +// SPDX-License-Identifier: GPL-2.0-or-later > > +/* > > + * Copyright (C) 2016 BayLibre, SAS > > + * Author: Neil Armstrong > > + * Copyright (C) 2015 Amlogic, Inc. All rights reserved. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > + > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > + > > +#include "meson_drv.h" > > +#include "meson_dw_mipi_dsi.h" > > +#include "meson_registers.h" > > +#include "meson_venc.h" > > + > > +#define DRIVER_NAME "meson-dw-mipi-dsi" > > +#define DRIVER_DESC "Amlogic Meson MIPI-DSI DRM driver" > > + > > +/* MIPI DSI/VENC Color Format Definitions */ > > +#define MIPI_DSI_VENC_COLOR_30B 0x0 > > +#define MIPI_DSI_VENC_COLOR_24B 0x1 > > +#define MIPI_DSI_VENC_COLOR_18B 0x2 > > +#define MIPI_DSI_VENC_COLOR_16B 0x3 > > + > > +#define COLOR_16BIT_CFG_1 0x0 > > +#define COLOR_16BIT_CFG_2 0x1 > > +#define COLOR_16BIT_CFG_3 0x2 > > +#define COLOR_18BIT_CFG_1 0x3 > > +#define COLOR_18BIT_CFG_2 0x4 > > +#define COLOR_24BIT 0x5 > > +#define COLOR_20BIT_LOOSE 0x6 > > +#define COLOR_24_BIT_YCBCR0x7 > > +#define COLOR_16BIT_YCBCR 0x8 > > +#define COLOR_30BIT 0x9 > > +#define COLOR_36BIT 0xa > > +#define COLOR_12BIT 0xb > > +#define COLOR_RGB_111 0xc > > +#define COLOR_RGB_332 0xd > > +#define COLOR_RGB_444 0xe > > + > > +/* MIPI DSI Relative REGISTERs Definitions */ > > +/* For MIPI_DSI_TOP_CNTL */ > > +#define BIT_DPI_COLOR_MODE20 > > +#define BIT_IN_COLOR_MODE 16 > > +#define BIT_CHROMA_SUBSAMPLE 14 > > +#define BIT_COMP2_SEL 12 > > +#define BIT_COMP1_SEL 10 > > +#define BIT_COMP0_SEL 8 > > +#define BIT_DE_POL 6 > > +#define BIT_HSYNC_POL 5 > > +#define BIT_VSYNC_POL 4 > > +#define BIT_DPICOLORM 3 > > +#define BIT_DPISH
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote: > The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a), > with a custom > glue managing the IP resets, clock and data input similar to the DW-HDMI Glue > on other > Amlogic SoCs. > > This adds support for the Glue managing the transceiver, mimicing the init > flow provided > by Amlogic to setup the ENCl encoder, the glue, the transceiver, the digital > D-PHY and the > Analog PHY in the proper way. > > The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 clock, > which pixel clock > is derived and feeds the ENCL encoder and the VIU pixel reader. > > An optional "MEAS" clock can be enabled to measure the delay between each > vsync feeding the > DW-MIPI-DSI transceiver. > > Signed-off-by: Neil Armstrong More dw-hdmi drivers which aren't bridges but components, and the thing is still midlayer-y as heck :-/ Can we try to fix this? There's a ton of this going on, and the more we add the old fashioned way the harder this gets to fix up for real. -Daniel > --- > drivers/gpu/drm/meson/Kconfig | 7 + > drivers/gpu/drm/meson/Makefile| 1 + > drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 562 ++ > 3 files changed, 570 insertions(+) > create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > > diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig > index 9f9281dd49f8..385f6f23839b 100644 > --- a/drivers/gpu/drm/meson/Kconfig > +++ b/drivers/gpu/drm/meson/Kconfig > @@ -16,3 +16,10 @@ config DRM_MESON_DW_HDMI > default y if DRM_MESON > select DRM_DW_HDMI > imply DRM_DW_HDMI_I2S_AUDIO > + > +config DRM_MESON_DW_MIPI_DSI > + tristate "MIPI DSI Synopsys Controller support for Amlogic Meson > Display" > + depends on DRM_MESON > + default y if DRM_MESON > + select DRM_DW_MIPI_DSI > + select GENERIC_PHY_MIPI_DPHY > diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile > index 28a519cdf66b..2cc870e91182 100644 > --- a/drivers/gpu/drm/meson/Makefile > +++ b/drivers/gpu/drm/meson/Makefile > @@ -5,3 +5,4 @@ meson-drm-y += meson_rdma.o meson_osd_afbcd.o > > obj-$(CONFIG_DRM_MESON) += meson-drm.o > obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o > +obj-$(CONFIG_DRM_MESON_DW_MIPI_DSI) += meson_dw_mipi_dsi.o > diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > new file mode 100644 > index ..bbe1294fce7c > --- /dev/null > +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > @@ -0,0 +1,562 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* > + * Copyright (C) 2016 BayLibre, SAS > + * Author: Neil Armstrong > + * Copyright (C) 2015 Amlogic, Inc. All rights reserved. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#include > +#include > + > +#include > +#include > +#include > +#include > + > +#include "meson_drv.h" > +#include "meson_dw_mipi_dsi.h" > +#include "meson_registers.h" > +#include "meson_venc.h" > + > +#define DRIVER_NAME "meson-dw-mipi-dsi" > +#define DRIVER_DESC "Amlogic Meson MIPI-DSI DRM driver" > + > +/* MIPI DSI/VENC Color Format Definitions */ > +#define MIPI_DSI_VENC_COLOR_30B 0x0 > +#define MIPI_DSI_VENC_COLOR_24B 0x1 > +#define MIPI_DSI_VENC_COLOR_18B 0x2 > +#define MIPI_DSI_VENC_COLOR_16B 0x3 > + > +#define COLOR_16BIT_CFG_1 0x0 > +#define COLOR_16BIT_CFG_2 0x1 > +#define COLOR_16BIT_CFG_3 0x2 > +#define COLOR_18BIT_CFG_1 0x3 > +#define COLOR_18BIT_CFG_2 0x4 > +#define COLOR_24BIT 0x5 > +#define COLOR_20BIT_LOOSE 0x6 > +#define COLOR_24_BIT_YCBCR0x7 > +#define COLOR_16BIT_YCBCR 0x8 > +#define COLOR_30BIT 0x9 > +#define COLOR_36BIT 0xa > +#define COLOR_12BIT 0xb > +#define COLOR_RGB_111 0xc > +#define COLOR_RGB_332 0xd > +#define COLOR_RGB_444 0xe > + > +/* MIPI DSI Relative REGISTERs Definitions */ > +/* For MIPI_DSI_TOP_CNTL */ > +#define BIT_DPI_COLOR_MODE20 > +#define BIT_IN_COLOR_MODE 16 > +#define BIT_CHROMA_SUBSAMPLE 14 > +#define BIT_COMP2_SEL 12 > +#define BIT_COMP1_SEL 10 > +#define BIT_COMP0_SEL 8 > +#define BIT_DE_POL 6 > +#define BIT_HSYNC_POL 5 > +#define BIT_VSYNC_POL 4 > +#define BIT_DPICOLORM 3 > +#define BIT_DPISHUTDN 2 > +#define BIT_EDPITE_INTR_PULSE 1 > +#define BIT_ERR_INTR_PULSE 0 > + > +/* HHI Registers */ > +#define HHI_VIID_CLK_DIV 0x128 /* 0x4a offset in data sheet */ > +#define VCLK2_DIV_MASK 0xff > +#define VCLK2_DIV_EN BIT(16) > +#define VCLK2_DIV_RESET BIT(17) > +#define CTS_ENCL_SEL_MASK(0xf << 12) > +#define CTS_ENCL_SEL_SHIF
[PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a),
with a custom
glue managing the IP resets, clock and data input similar to the DW-HDMI Glue
on other
Amlogic SoCs.
This adds support for the Glue managing the transceiver, mimicing the init flow
provided
by Amlogic to setup the ENCl encoder, the glue, the transceiver, the digital
D-PHY and the
Analog PHY in the proper way.
The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 clock,
which pixel clock
is derived and feeds the ENCL encoder and the VIU pixel reader.
An optional "MEAS" clock can be enabled to measure the delay between each vsync
feeding the
DW-MIPI-DSI transceiver.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/Kconfig | 7 +
drivers/gpu/drm/meson/Makefile| 1 +
drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 562 ++
3 files changed, 570 insertions(+)
create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig
index 9f9281dd49f8..385f6f23839b 100644
--- a/drivers/gpu/drm/meson/Kconfig
+++ b/drivers/gpu/drm/meson/Kconfig
@@ -16,3 +16,10 @@ config DRM_MESON_DW_HDMI
default y if DRM_MESON
select DRM_DW_HDMI
imply DRM_DW_HDMI_I2S_AUDIO
+
+config DRM_MESON_DW_MIPI_DSI
+ tristate "MIPI DSI Synopsys Controller support for Amlogic Meson
Display"
+ depends on DRM_MESON
+ default y if DRM_MESON
+ select DRM_DW_MIPI_DSI
+ select GENERIC_PHY_MIPI_DPHY
diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile
index 28a519cdf66b..2cc870e91182 100644
--- a/drivers/gpu/drm/meson/Makefile
+++ b/drivers/gpu/drm/meson/Makefile
@@ -5,3 +5,4 @@ meson-drm-y += meson_rdma.o meson_osd_afbcd.o
obj-$(CONFIG_DRM_MESON) += meson-drm.o
obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o
+obj-$(CONFIG_DRM_MESON_DW_MIPI_DSI) += meson_dw_mipi_dsi.o
diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
new file mode 100644
index ..bbe1294fce7c
--- /dev/null
+++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
@@ -0,0 +1,562 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2016 BayLibre, SAS
+ * Author: Neil Armstrong
+ * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "meson_drv.h"
+#include "meson_dw_mipi_dsi.h"
+#include "meson_registers.h"
+#include "meson_venc.h"
+
+#define DRIVER_NAME "meson-dw-mipi-dsi"
+#define DRIVER_DESC "Amlogic Meson MIPI-DSI DRM driver"
+
+/* MIPI DSI/VENC Color Format Definitions */
+#define MIPI_DSI_VENC_COLOR_30B 0x0
+#define MIPI_DSI_VENC_COLOR_24B 0x1
+#define MIPI_DSI_VENC_COLOR_18B 0x2
+#define MIPI_DSI_VENC_COLOR_16B 0x3
+
+#define COLOR_16BIT_CFG_1 0x0
+#define COLOR_16BIT_CFG_2 0x1
+#define COLOR_16BIT_CFG_3 0x2
+#define COLOR_18BIT_CFG_1 0x3
+#define COLOR_18BIT_CFG_2 0x4
+#define COLOR_24BIT 0x5
+#define COLOR_20BIT_LOOSE 0x6
+#define COLOR_24_BIT_YCBCR0x7
+#define COLOR_16BIT_YCBCR 0x8
+#define COLOR_30BIT 0x9
+#define COLOR_36BIT 0xa
+#define COLOR_12BIT 0xb
+#define COLOR_RGB_111 0xc
+#define COLOR_RGB_332 0xd
+#define COLOR_RGB_444 0xe
+
+/* MIPI DSI Relative REGISTERs Definitions */
+/* For MIPI_DSI_TOP_CNTL */
+#define BIT_DPI_COLOR_MODE20
+#define BIT_IN_COLOR_MODE 16
+#define BIT_CHROMA_SUBSAMPLE 14
+#define BIT_COMP2_SEL 12
+#define BIT_COMP1_SEL 10
+#define BIT_COMP0_SEL 8
+#define BIT_DE_POL 6
+#define BIT_HSYNC_POL 5
+#define BIT_VSYNC_POL 4
+#define BIT_DPICOLORM 3
+#define BIT_DPISHUTDN 2
+#define BIT_EDPITE_INTR_PULSE 1
+#define BIT_ERR_INTR_PULSE 0
+
+/* HHI Registers */
+#define HHI_VIID_CLK_DIV 0x128 /* 0x4a offset in data sheet */
+#define VCLK2_DIV_MASK 0xff
+#define VCLK2_DIV_EN BIT(16)
+#define VCLK2_DIV_RESETBIT(17)
+#define CTS_ENCL_SEL_MASK (0xf << 12)
+#define CTS_ENCL_SEL_SHIFT 12
+#define HHI_VIID_CLK_CNTL 0x12c /* 0x4b offset in data sheet */
+#define VCLK2_EN BIT(19)
+#define VCLK2_SEL_MASK (0x7 << 16)
+#define VCLK2_SEL_SHIFT16
+#define VCLK2_SOFT_RESET BIT(15)
+#define VCLK2_DIV1_EN BIT(0)
+#define HHI_VID_CLK_CNTL2 0x194 /* 0x65 offset in data sheet */
+#define CTS_ENCL_ENBIT(3)
+
+/**
+ * DOC: MIPI DSI
+ *
+ */
+
+struct meson_dw_mipi_dsi {
+ struct drm_encoder encoder;
+ struct meson_drm *priv;
+ struct device *dev;
+ void __iomem *ba
