devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <Dharma.B@microchip.com>
To: <krzk@kernel.org>, <Manikandan.M@microchip.com>,
	<andrzej.hajda@intel.com>, <neil.armstrong@linaro.org>,
	<rfoss@kernel.org>, <Laurent.pinchart@ideasonboard.com>,
	<jonas@kwiboo.se>, <jernej.skrabec@gmail.com>,
	<airlied@gmail.com>, <daniel@ffwll.ch>,
	<maarten.lankhorst@linux.intel.com>, <mripard@kernel.org>,
	<tzimmermann@suse.de>, <robh+dt@kernel.org>,
	<krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
	<dri-devel@lists.freedesktop.org>, <devicetree@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Cc: <Linux4Microchip@microchip.com>
Subject: Re: [PATCH 2/3] drm/bridge: add lvds controller support for sam9x7
Date: Tue, 23 Jan 2024 08:26:33 +0000	[thread overview]
Message-ID: <eb873f4e-7804-4460-ad0a-619689e2786e@microchip.com> (raw)
In-Reply-To: <7cd4d9f9-e14a-4cd4-92f7-51c43acd23e2@kernel.org>

Hi Krzysztof,

On 22/01/24 9:19 pm, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 22/01/2024 09:29, Dharma Balasubiramani wrote:
>> Add a new LVDS controller driver for sam9x7 which does the following:
>> - Prepares and enables the LVDS Peripheral clock
>> - Defines its connector type as DRM_MODE_CONNECTOR_LVDS and adds itself
>> to the global bridge list.
>> - Identifies its output endpoint as panel and adds it to the encoder
>> display pipeline
>> - Enables the LVDS serializer
>>
>> Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
>> Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>
>> ---
> 
> ...
> 
>> +
>> +static int mchp_lvds_probe(struct platform_device *pdev)
>> +{
>> +     struct device *dev = &pdev->dev;
>> +     struct mchp_lvds *lvds;
>> +     struct resource *res;
>> +     struct device_node *port;
>> +     int ret;
>> +
>> +     if (!dev->of_node)
>> +             return -ENODEV;
>> +
>> +     lvds = devm_kzalloc(&pdev->dev, sizeof(*lvds), GFP_KERNEL);
>> +     if (!lvds)
>> +             return -ENOMEM;
>> +
>> +     lvds->dev = dev;
>> +
>> +     res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +     lvds->regs = devm_ioremap_resource(lvds->dev, res);
> 
> Why not combining these two?

It seems reasonable to combine these two lines since the resource 
variable (res) is only used at this point. I'll proceed with 
consolidating these lines for simplicity.

> 
>> +     if (IS_ERR(lvds->regs))
>> +             return PTR_ERR(lvds->regs);
>> +
>> +     lvds->pclk = devm_clk_get(lvds->dev, "pclk");
>> +     if (IS_ERR(lvds->pclk)) {
>> +             DRM_DEV_ERROR(lvds->dev, "could not get pclk_lvds\n");
> 
> Handle properly deferred probe. What's DRM wrapper over dev_err_probe()?
Sure, I will use dev_err_probe()

return dev_err_probe(lvds->dev, PTR_ERR(lvds->pclk), "could not get 
pclk_lvds\n");

> 
>> +             return PTR_ERR(lvds->pclk);
>> +     }
>> +
>> +     ret = clk_prepare(lvds->pclk);
>> +     if (ret < 0) {
>> +             DRM_DEV_ERROR(lvds->dev, "failed to prepare pclk_lvds\n");
>> +             return ret;
>> +     }
>> +
>> +     port = of_graph_get_remote_node(dev->of_node, 1, 0);
>> +     if (!port) {
>> +             DRM_DEV_ERROR(dev,
>> +                           "can't find port point, please init lvds panel port!\n");
>> +             return -EINVAL;
>> +     }
>> +
>> +     lvds->panel = of_drm_find_panel(port);
>> +     of_node_put(port);
>> +
>> +     if (IS_ERR(lvds->panel)) {
>> +             DRM_DEV_ERROR(dev, "failed to find panel node\n");
>> +             return -EPROBE_DEFER;
> 
> OK, that's for sure wrong. Don't print anything on deferred probe.
Sure, I will drop the print here.
> 
>> +     }
>> +
>> +     lvds->panel_bridge = devm_drm_panel_bridge_add(dev, lvds->panel);
>> +
>> +     if (IS_ERR(lvds->panel_bridge))
>> +             return PTR_ERR(lvds->panel_bridge);
>> +
>> +     lvds->bridge.of_node = dev->of_node;
>> +     lvds->bridge.type = DRM_MODE_CONNECTOR_LVDS;
>> +     lvds->bridge.funcs = &mchp_lvds_bridge_funcs;
>> +
>> +     dev_set_drvdata(dev, lvds);
>> +     pm_runtime_enable(dev);
>> +
>> +     drm_bridge_add(&lvds->bridge);
>> +
>> +     return 0;
>> +}
>> +
>> +static int mchp_lvds_remove(struct platform_device *pdev)
>> +{
>> +     struct mchp_lvds *lvds = platform_get_drvdata(pdev);
>> +
>> +     pm_runtime_disable(&pdev->dev);
>> +     clk_unprepare(lvds->pclk);
>> +
>> +     return 0;
>> +}
>> +
>> +static const struct of_device_id mchp_lvds_dt_ids[] = {
>> +     {
>> +             .compatible = "microchip,sam9x7-lvds",
>> +     },
>> +     {},
>> +};
>> +
>> +struct platform_driver mchp_lvds_driver = {
>> +     .probe = mchp_lvds_probe,
>> +     .remove = mchp_lvds_remove,
>> +     .driver = {
>> +                .name = "microchip-lvds",
>> +                .of_match_table = mchp_lvds_dt_ids,
>> +     },
>> +};
>> +module_platform_driver(mchp_lvds_driver);
>> +
>> +MODULE_AUTHOR("Manikandan Muralidharan <manikandan.m@microchip.com>");
>> +MODULE_AUTHOR("Dharma Balasubiramani <dharma.b@microchip.com>");
>> +MODULE_DESCRIPTION("Low Voltage Differential Signaling Controller Driver");
>> +MODULE_LICENSE("GPL");
>> +MODULE_ALIAS("platform:microchip-lvds");
> 
> You should not need MODULE_ALIAS() in normal cases. If you need it,
> usually it means your device ID table is wrong (e.g. misses either
> entries or MODULE_DEVICE_TABLE()). MODULE_ALIAS() is not a substitute
> for incomplete ID table.

Okay, I will remove the MODULE_ALIAS and update the mchp_lvds_dt_ids[] 
as below along with MODULE_DEVICE_TABLE()

static const struct of_device_id mchp_lvds_dt_ids[] = {
         {
                 .compatible = "microchip,sam9x72-lvds",
         },
         {
                 .compatible = "microchip,sam9x75-lvds",
         },
         {},
};
MODULE_DEVICE_TABLE(of, mchp_lvds_dt_ids);

-- 
Thanks,
Dharma B.
> 
> 
> Best regards,
> Krzysztof
> 




  reply	other threads:[~2024-01-23  8:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-22  8:29 [PATCH 0/3] LVDS Controller Support for SAM9X7 SoC Dharma Balasubiramani
2024-01-22  8:29 ` [PATCH 1/3] dt-bindings: display: bridge: add sam9x7-lvds compatible Dharma Balasubiramani
2024-01-22 15:51   ` Krzysztof Kozlowski
2024-01-22 16:37     ` Conor Dooley
2024-01-23  3:39       ` Dharma.B
2024-01-30 19:12         ` Rob Herring
2024-02-01  4:10           ` Dharma.B
2024-02-01  7:39             ` Krzysztof Kozlowski
2024-02-01  8:56               ` Dharma.B
2024-01-23  3:30     ` Dharma.B
2024-01-22  8:29 ` [PATCH 2/3] drm/bridge: add lvds controller support for sam9x7 Dharma Balasubiramani
2024-01-22 15:49   ` Krzysztof Kozlowski
2024-01-23  8:26     ` Dharma.B [this message]
2024-02-03 14:20   ` kernel test robot
2024-01-22  8:29 ` [PATCH 3/3] MAINTAINERS: add SAM9X7 SoC's LVDS controller Dharma Balasubiramani

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=eb873f4e-7804-4460-ad0a-619689e2786e@microchip.com \
    --to=dharma.b@microchip.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=Linux4Microchip@microchip.com \
    --cc=Manikandan.M@microchip.com \
    --cc=airlied@gmail.com \
    --cc=andrzej.hajda@intel.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=krzk@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=rfoss@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=tzimmermann@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).