From: jacopo mondi <jacopo@jmondi.org>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: Jacopo Mondi <jacopo+renesas@jmondi.org>,
architt@codeaurora.org, Laurent.pinchart@ideasonboard.com,
airlied@linux.ie, horms@verge.net.au, magnus.damm@gmail.com,
geert@linux-m68k.org, niklas.soderlund@ragnatech.se,
sergei.shtylyov@cogentembedded.com, robh+dt@kernel.org,
mark.rutland@arm.com, dri-devel@lists.freedesktop.org,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
Date: Thu, 15 Mar 2018 11:30:27 +0100 [thread overview]
Message-ID: <20180315103027.GE16424@w540> (raw)
In-Reply-To: <4204d21d-080f-b275-1f89-828cfdcdf90a@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 6239 bytes --]
HI Andrezej,
On Thu, Mar 15, 2018 at 10:44:42AM +0100, Andrzej Hajda wrote:
> On 14.03.2018 11:09, jacopo mondi wrote:
> > Hi Andrzej,
> > thanks for review
> >
> > On Wed, Mar 14, 2018 at 09:42:36AM +0100, Andrzej Hajda wrote:
> >> On 13.03.2018 15:30, Jacopo Mondi wrote:
> >>> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> >>> output decoder.
> >> IMO converter suits here better, but it is just suggestion.
> >>
> >>> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> >>> ---
> >>> drivers/gpu/drm/bridge/Kconfig | 7 +
> >>> drivers/gpu/drm/bridge/Makefile | 1 +
> >>> drivers/gpu/drm/bridge/thc63lvd1024.c | 241 ++++++++++++++++++++++++++++++++++
> >>> 3 files changed, 249 insertions(+)
> >>> create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> >>> index 3b99d5a..facf6bd 100644
> >>> --- a/drivers/gpu/drm/bridge/Kconfig
> >>> +++ b/drivers/gpu/drm/bridge/Kconfig
> >>> @@ -92,6 +92,13 @@ config DRM_SII9234
> >>> It is an I2C driver, that detects connection of MHL bridge
> >>> and starts encapsulation of HDMI signal.
> >>>
> >>> +config DRM_THINE_THC63LVD1024
> >>> + tristate "Thine THC63LVD1024 LVDS decoder bridge"
> >>> + depends on OF
> >>> + select DRM_PANEL_BRIDGE
> >> You don't use PANEL_BRIDGE, it should be possible to drop the select.
> >>
> > Ack
> >
> >>> + ---help---
> >>> + Thine THC63LVD1024 LVDS decoder bridge driver.
> >> Decoder to what?
> >> Maybe it would be better to say it is LVDS/parallel or LVDS/RGB
> >> converter or bridge.
> > "LVDS to digital CMOS/TTL parallel data converter" as the manual
> > describes the chip?
>
> Should work, unless we want some consistency in interface names, we have
> already: parallel / DPI / RGB. I am little bit confused about relations
> between them so I do not want to enforce any.
config DRM_THINE_THC63LVD1024
tristate "Thine THC63LVD1024 LVDS decoder bridge"
depends on OF
---help---
Thine THC63LVD1024 LVDS/parallel converter driver.
I guess this is consistent with other symbol descriptions I found
>
[snip]
>
> >>> +
> >>> +static int thc63_gpio_init(struct thc63_dev *thc63)
> >>> +{
> >>> + thc63->pwdn = devm_gpiod_get_optional(thc63->dev, "pwdn",
> >>> + GPIOD_OUT_LOW);
> >> Shouldn't be GPIOD_OUT_HIGH - bridge initially disabled?
> > No, the PWDN gpio is active low, it puts the chip in power down mode
> > when the physical line level is set to 0.
> >
> > That's another confusing thing, when requesting the GPIO, the actual
> > physical line value has to be provided, while when "set_value()" the
> > logical one is requested, iirc.
>
> I think it is opposite, only *raw* functions uses physical level. Other
> uses logical level.
>
> >
> > Being the GPIO defined as active low, in power enable we set it to
> > "logical inactive" == "physical 1", while during power disable it has
> > to be set to "logical active" == "physical 0"
> >
> > Not the right place to complain here, but imo that's not consistent.
> > Or have I misinterpreted the APIs? I cannot do much test, as in my setup
> > the PWDN pin is hardwired to +vcc (through a physical switch, not
> > controlled through a GPIO though).
>
> devm_gpiod_get_optional calls (indirectly) gpiod_configure_flags, which
> calls gpiod_direction_output which uses logical levels.
I clearly mis-interpreted the APIs.
I'll fix and I'm sending v4 out shortly.
Thanks
j
>
> Regards
> Andrzej
>
> >
> > Thanks
> > j
> >
> >> Regards
> >> Andrzej
> >>> + if (IS_ERR(thc63->pwdn)) {
> >>> + dev_err(thc63->dev, "Unable to get GPIO \"pwdn\"\n");
> >>> + return PTR_ERR(thc63->pwdn);
> >>> + }
> >>> +
> >>> + thc63->oe = devm_gpiod_get_optional(thc63->dev, "oe", GPIOD_OUT_LOW);
> >>> + if (IS_ERR(thc63->oe)) {
> >>> + dev_err(thc63->dev, "Unable to get GPIO \"oe\"\n");
> >>> + return PTR_ERR(thc63->oe);
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int thc63_regulator_init(struct thc63_dev *thc63)
> >>> +{
> >>> + struct regulator **reg;
> >>> + int i;
> >>> +
> >>> + reg = &thc63->vccs[0];
> >>> + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++, reg++) {
> >>> + *reg = devm_regulator_get_optional(thc63->dev,
> >>> + thc63_reg_names[i]);
> >>> + if (IS_ERR(*reg)) {
> >>> + if (PTR_ERR(*reg) == -EPROBE_DEFER)
> >>> + return -EPROBE_DEFER;
> >>> + *reg = NULL;
> >>> + }
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int thc63_probe(struct platform_device *pdev)
> >>> +{
> >>> + struct thc63_dev *thc63;
> >>> + int ret;
> >>> +
> >>> + thc63 = devm_kzalloc(&pdev->dev, sizeof(*thc63), GFP_KERNEL);
> >>> + if (!thc63)
> >>> + return -ENOMEM;
> >>> +
> >>> + thc63->dev = &pdev->dev;
> >>> + platform_set_drvdata(pdev, thc63);
> >>> +
> >>> + ret = thc63_regulator_init(thc63);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + ret = thc63_gpio_init(thc63);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + ret = thc63_parse_dt(thc63);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + thc63->bridge.driver_private = thc63;
> >>> + thc63->bridge.of_node = pdev->dev.of_node;
> >>> + thc63->bridge.funcs = &thc63_bridge_func;
> >>> +
> >>> + drm_bridge_add(&thc63->bridge);
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int thc63_remove(struct platform_device *pdev)
> >>> +{
> >>> + struct thc63_dev *thc63 = platform_get_drvdata(pdev);
> >>> +
> >>> + drm_bridge_remove(&thc63->bridge);
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +#ifdef CONFIG_OF
> >>> +static const struct of_device_id thc63_match[] = {
> >>> + { .compatible = "thine,thc63lvd1024", },
> >>> + { },
> >>> +};
> >>> +MODULE_DEVICE_TABLE(of, thc63_match);
> >>> +#endif
> >>> +
> >>> +static struct platform_driver thc63_driver = {
> >>> + .probe = thc63_probe,
> >>> + .remove = thc63_remove,
> >>> + .driver = {
> >>> + .name = "thc63lvd1024",
> >>> + .of_match_table = thc63_match,
> >>> + },
> >>> +};
> >>> +module_platform_driver(thc63_driver);
> >>> +
> >>> +MODULE_AUTHOR("Jacopo Mondi <jacopo@jmondi.org>");
> >>> +MODULE_DESCRIPTION("Thine THC63LVD1024 LVDS decoder DRM bridge driver");
> >>> +MODULE_LICENSE("GPL v2");
> >>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: jacopo mondi <jacopo@jmondi.org>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
sergei.shtylyov@cogentembedded.com, airlied@linux.ie,
dri-devel@lists.freedesktop.org, magnus.damm@gmail.com,
linux-kernel@vger.kernel.org, robh+dt@kernel.org,
linux-renesas-soc@vger.kernel.org, horms@verge.net.au,
Jacopo Mondi <jacopo+renesas@jmondi.org>,
Laurent.pinchart@ideasonboard.com, niklas.soderlund@ragnatech.se,
geert@linux-m68k.org
Subject: Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
Date: Thu, 15 Mar 2018 11:30:27 +0100 [thread overview]
Message-ID: <20180315103027.GE16424@w540> (raw)
In-Reply-To: <4204d21d-080f-b275-1f89-828cfdcdf90a@samsung.com>
[-- Attachment #1.1: Type: text/plain, Size: 6239 bytes --]
HI Andrezej,
On Thu, Mar 15, 2018 at 10:44:42AM +0100, Andrzej Hajda wrote:
> On 14.03.2018 11:09, jacopo mondi wrote:
> > Hi Andrzej,
> > thanks for review
> >
> > On Wed, Mar 14, 2018 at 09:42:36AM +0100, Andrzej Hajda wrote:
> >> On 13.03.2018 15:30, Jacopo Mondi wrote:
> >>> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> >>> output decoder.
> >> IMO converter suits here better, but it is just suggestion.
> >>
> >>> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> >>> ---
> >>> drivers/gpu/drm/bridge/Kconfig | 7 +
> >>> drivers/gpu/drm/bridge/Makefile | 1 +
> >>> drivers/gpu/drm/bridge/thc63lvd1024.c | 241 ++++++++++++++++++++++++++++++++++
> >>> 3 files changed, 249 insertions(+)
> >>> create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> >>> index 3b99d5a..facf6bd 100644
> >>> --- a/drivers/gpu/drm/bridge/Kconfig
> >>> +++ b/drivers/gpu/drm/bridge/Kconfig
> >>> @@ -92,6 +92,13 @@ config DRM_SII9234
> >>> It is an I2C driver, that detects connection of MHL bridge
> >>> and starts encapsulation of HDMI signal.
> >>>
> >>> +config DRM_THINE_THC63LVD1024
> >>> + tristate "Thine THC63LVD1024 LVDS decoder bridge"
> >>> + depends on OF
> >>> + select DRM_PANEL_BRIDGE
> >> You don't use PANEL_BRIDGE, it should be possible to drop the select.
> >>
> > Ack
> >
> >>> + ---help---
> >>> + Thine THC63LVD1024 LVDS decoder bridge driver.
> >> Decoder to what?
> >> Maybe it would be better to say it is LVDS/parallel or LVDS/RGB
> >> converter or bridge.
> > "LVDS to digital CMOS/TTL parallel data converter" as the manual
> > describes the chip?
>
> Should work, unless we want some consistency in interface names, we have
> already: parallel / DPI / RGB. I am little bit confused about relations
> between them so I do not want to enforce any.
config DRM_THINE_THC63LVD1024
tristate "Thine THC63LVD1024 LVDS decoder bridge"
depends on OF
---help---
Thine THC63LVD1024 LVDS/parallel converter driver.
I guess this is consistent with other symbol descriptions I found
>
[snip]
>
> >>> +
> >>> +static int thc63_gpio_init(struct thc63_dev *thc63)
> >>> +{
> >>> + thc63->pwdn = devm_gpiod_get_optional(thc63->dev, "pwdn",
> >>> + GPIOD_OUT_LOW);
> >> Shouldn't be GPIOD_OUT_HIGH - bridge initially disabled?
> > No, the PWDN gpio is active low, it puts the chip in power down mode
> > when the physical line level is set to 0.
> >
> > That's another confusing thing, when requesting the GPIO, the actual
> > physical line value has to be provided, while when "set_value()" the
> > logical one is requested, iirc.
>
> I think it is opposite, only *raw* functions uses physical level. Other
> uses logical level.
>
> >
> > Being the GPIO defined as active low, in power enable we set it to
> > "logical inactive" == "physical 1", while during power disable it has
> > to be set to "logical active" == "physical 0"
> >
> > Not the right place to complain here, but imo that's not consistent.
> > Or have I misinterpreted the APIs? I cannot do much test, as in my setup
> > the PWDN pin is hardwired to +vcc (through a physical switch, not
> > controlled through a GPIO though).
>
> devm_gpiod_get_optional calls (indirectly) gpiod_configure_flags, which
> calls gpiod_direction_output which uses logical levels.
I clearly mis-interpreted the APIs.
I'll fix and I'm sending v4 out shortly.
Thanks
j
>
> Regards
> Andrzej
>
> >
> > Thanks
> > j
> >
> >> Regards
> >> Andrzej
> >>> + if (IS_ERR(thc63->pwdn)) {
> >>> + dev_err(thc63->dev, "Unable to get GPIO \"pwdn\"\n");
> >>> + return PTR_ERR(thc63->pwdn);
> >>> + }
> >>> +
> >>> + thc63->oe = devm_gpiod_get_optional(thc63->dev, "oe", GPIOD_OUT_LOW);
> >>> + if (IS_ERR(thc63->oe)) {
> >>> + dev_err(thc63->dev, "Unable to get GPIO \"oe\"\n");
> >>> + return PTR_ERR(thc63->oe);
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int thc63_regulator_init(struct thc63_dev *thc63)
> >>> +{
> >>> + struct regulator **reg;
> >>> + int i;
> >>> +
> >>> + reg = &thc63->vccs[0];
> >>> + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++, reg++) {
> >>> + *reg = devm_regulator_get_optional(thc63->dev,
> >>> + thc63_reg_names[i]);
> >>> + if (IS_ERR(*reg)) {
> >>> + if (PTR_ERR(*reg) == -EPROBE_DEFER)
> >>> + return -EPROBE_DEFER;
> >>> + *reg = NULL;
> >>> + }
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int thc63_probe(struct platform_device *pdev)
> >>> +{
> >>> + struct thc63_dev *thc63;
> >>> + int ret;
> >>> +
> >>> + thc63 = devm_kzalloc(&pdev->dev, sizeof(*thc63), GFP_KERNEL);
> >>> + if (!thc63)
> >>> + return -ENOMEM;
> >>> +
> >>> + thc63->dev = &pdev->dev;
> >>> + platform_set_drvdata(pdev, thc63);
> >>> +
> >>> + ret = thc63_regulator_init(thc63);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + ret = thc63_gpio_init(thc63);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + ret = thc63_parse_dt(thc63);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + thc63->bridge.driver_private = thc63;
> >>> + thc63->bridge.of_node = pdev->dev.of_node;
> >>> + thc63->bridge.funcs = &thc63_bridge_func;
> >>> +
> >>> + drm_bridge_add(&thc63->bridge);
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int thc63_remove(struct platform_device *pdev)
> >>> +{
> >>> + struct thc63_dev *thc63 = platform_get_drvdata(pdev);
> >>> +
> >>> + drm_bridge_remove(&thc63->bridge);
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +#ifdef CONFIG_OF
> >>> +static const struct of_device_id thc63_match[] = {
> >>> + { .compatible = "thine,thc63lvd1024", },
> >>> + { },
> >>> +};
> >>> +MODULE_DEVICE_TABLE(of, thc63_match);
> >>> +#endif
> >>> +
> >>> +static struct platform_driver thc63_driver = {
> >>> + .probe = thc63_probe,
> >>> + .remove = thc63_remove,
> >>> + .driver = {
> >>> + .name = "thc63lvd1024",
> >>> + .of_match_table = thc63_match,
> >>> + },
> >>> +};
> >>> +module_platform_driver(thc63_driver);
> >>> +
> >>> +MODULE_AUTHOR("Jacopo Mondi <jacopo@jmondi.org>");
> >>> +MODULE_DESCRIPTION("Thine THC63LVD1024 LVDS decoder DRM bridge driver");
> >>> +MODULE_LICENSE("GPL v2");
> >>
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-03-15 10:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-13 14:30 [PATCH v3 0/3] drm: Add Thine THC63LVD1024 LVDS decoder bridge Jacopo Mondi
2018-03-13 14:30 ` [PATCH v3 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder Jacopo Mondi
2018-03-14 8:15 ` Andrzej Hajda
2018-03-14 8:15 ` Andrzej Hajda
2018-03-14 9:06 ` jacopo mondi
2018-03-14 9:06 ` jacopo mondi
2018-03-20 12:30 ` Laurent Pinchart
2018-03-20 12:30 ` Laurent Pinchart
2018-03-13 14:30 ` [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver Jacopo Mondi
2018-03-14 8:42 ` Andrzej Hajda
2018-03-14 8:42 ` Andrzej Hajda
2018-03-14 10:09 ` jacopo mondi
2018-03-14 10:09 ` jacopo mondi
2018-03-15 9:44 ` Andrzej Hajda
2018-03-15 9:44 ` Andrzej Hajda
2018-03-15 10:30 ` jacopo mondi [this message]
2018-03-15 10:30 ` jacopo mondi
2018-03-14 17:09 ` Sergei Shtylyov
2018-03-14 18:04 ` jacopo mondi
2018-03-14 18:17 ` Sergei Shtylyov
2018-03-14 18:17 ` Sergei Shtylyov
2018-03-13 14:30 ` [PATCH v3 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle Jacopo Mondi
2018-03-13 18:47 ` Simon Horman
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=20180315103027.GE16424@w540 \
--to=jacopo@jmondi.org \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=airlied@linux.ie \
--cc=architt@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=geert@linux-m68k.org \
--cc=horms@verge.net.au \
--cc=jacopo+renesas@jmondi.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=mark.rutland@arm.com \
--cc=niklas.soderlund@ragnatech.se \
--cc=robh+dt@kernel.org \
--cc=sergei.shtylyov@cogentembedded.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: link
Be 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.