All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neal Liu <neal.liu@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Neal Liu <neal.liu@mediatek.com>,
	Rob Herring <robh+dt@kernel.org>,
	Chun-Kuang Hu <chunkuang.hu@kernel.org>,
	<devicetree@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	lkml <linux-kernel@vger.kernel.org>, <wsd_upstream@mediatek.com>
Subject: Re: [PATCH v7 2/2] soc: mediatek: add mt6779 devapc driver
Date: Mon, 12 Oct 2020 11:24:58 +0800	[thread overview]
Message-ID: <1602473098.26774.5.camel@mtkswgap22> (raw)
In-Reply-To: <0ece983b-2e55-cf06-aca8-02a014fce090@gmail.com>

On Fri, 2020-10-09 at 14:34 +0200, Matthias Brugger wrote:
> 
> On 08/10/2020 11:39, Neal Liu wrote:
> > On Thu, 2020-10-08 at 10:45 +0200, Matthias Brugger wrote:
> >>
> >> On 08/10/2020 04:35, Neal Liu wrote:
> >>> On Wed, 2020-10-07 at 12:44 +0200, Matthias Brugger wrote:
> >>>>
> >>>> On 27/08/2020 05:06, Neal Liu wrote:
> [...]
> 
> >>>>> +static int mtk_devapc_probe(struct platform_device *pdev)
> >>>>> +{
> >>>>> +	struct device_node *node = pdev->dev.of_node;
> >>>>> +	struct mtk_devapc_context *ctx;
> >>>>> +	u32 devapc_irq;
> >>>>> +	int ret;
> >>>>> +
> >>>>> +	if (IS_ERR(node))
> >>>>> +		return -ENODEV;
> >>>>> +
> >>>>> +	ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
> >>>>> +	if (!ctx)
> >>>>> +		return -ENOMEM;
> >>>>> +
> >>>>> +	ctx->data = of_device_get_match_data(&pdev->dev);
> >>>>> +	ctx->dev = &pdev->dev;
> >>>>> +
> >>>>> +	ctx->infra_base = of_iomap(node, 0);
> >>>>
> >>>> Does this mean the device is part of the infracfg block?
> >>>> I wasn't able to find any information about it.
> >>>
> >>> I'm not sure why you would ask infracfg block. devapc is parts of our
> >>> SoC infra, it's different with infracfg.
> >>>
> >>
> >> I'm asking because I want to understand the HW better. I'm not able to find any
> >> information in the datasheets. I want to avoid a situation as we had with the
> >> MMSYS where a clock driver was submitted first and later on we realized that
> >> MMSYS is much more then that and we had to work hard to get the driver right.
> >>
> >> Now it's happening with SCPSYS, where a driver with the scpsys compatible was
> >> send years ago. But SCPSYS is much more then the driver submitted. In this case
> >> we opted to write a new driver, but moving from one driver to another one is
> >> painfull and full of problems. For that I want to make sure we fully understand
> >> Device APC (by the way, what does APC stands for?). Is it a totally independent
> >> HW block or is it part of a subsystem, like for example SCP?
> >>
> >> Regards,
> >> Matthias
> > 
> > It's a totally independent HW block instead of a subsystem.
> > I think it's more simple than MMSYS or SCPSYS. But if you would like to
> > understand more about this HW, we could find another way/channel to
> > introduce it.
> > 
> 
> If it's a independent HW block, then we are good. No further information needed 
> by me. I'd just advise to rename the infra_base to something like base, as it 
> made me confuse.
> 
> Thanks!
> Matthias

You can imagine that infra_base means infra devapc base address for
MT6779. In 5G platforms, MediaTek infrastructure would separate into
multiple parts, so does devapc HW. And devapc would be like:
infra_base, peri_base, peri2_base, ...

Thanks.


WARNING: multiple messages have this Message-ID (diff)
From: Neal Liu <neal.liu@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org>,
	wsd_upstream@mediatek.com, devicetree@vger.kernel.org,
	lkml <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	linux-mediatek@lists.infradead.org,
	Neal Liu <neal.liu@mediatek.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 2/2] soc: mediatek: add mt6779 devapc driver
Date: Mon, 12 Oct 2020 11:24:58 +0800	[thread overview]
Message-ID: <1602473098.26774.5.camel@mtkswgap22> (raw)
In-Reply-To: <0ece983b-2e55-cf06-aca8-02a014fce090@gmail.com>

On Fri, 2020-10-09 at 14:34 +0200, Matthias Brugger wrote:
> 
> On 08/10/2020 11:39, Neal Liu wrote:
> > On Thu, 2020-10-08 at 10:45 +0200, Matthias Brugger wrote:
> >>
> >> On 08/10/2020 04:35, Neal Liu wrote:
> >>> On Wed, 2020-10-07 at 12:44 +0200, Matthias Brugger wrote:
> >>>>
> >>>> On 27/08/2020 05:06, Neal Liu wrote:
> [...]
> 
> >>>>> +static int mtk_devapc_probe(struct platform_device *pdev)
> >>>>> +{
> >>>>> +	struct device_node *node = pdev->dev.of_node;
> >>>>> +	struct mtk_devapc_context *ctx;
> >>>>> +	u32 devapc_irq;
> >>>>> +	int ret;
> >>>>> +
> >>>>> +	if (IS_ERR(node))
> >>>>> +		return -ENODEV;
> >>>>> +
> >>>>> +	ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
> >>>>> +	if (!ctx)
> >>>>> +		return -ENOMEM;
> >>>>> +
> >>>>> +	ctx->data = of_device_get_match_data(&pdev->dev);
> >>>>> +	ctx->dev = &pdev->dev;
> >>>>> +
> >>>>> +	ctx->infra_base = of_iomap(node, 0);
> >>>>
> >>>> Does this mean the device is part of the infracfg block?
> >>>> I wasn't able to find any information about it.
> >>>
> >>> I'm not sure why you would ask infracfg block. devapc is parts of our
> >>> SoC infra, it's different with infracfg.
> >>>
> >>
> >> I'm asking because I want to understand the HW better. I'm not able to find any
> >> information in the datasheets. I want to avoid a situation as we had with the
> >> MMSYS where a clock driver was submitted first and later on we realized that
> >> MMSYS is much more then that and we had to work hard to get the driver right.
> >>
> >> Now it's happening with SCPSYS, where a driver with the scpsys compatible was
> >> send years ago. But SCPSYS is much more then the driver submitted. In this case
> >> we opted to write a new driver, but moving from one driver to another one is
> >> painfull and full of problems. For that I want to make sure we fully understand
> >> Device APC (by the way, what does APC stands for?). Is it a totally independent
> >> HW block or is it part of a subsystem, like for example SCP?
> >>
> >> Regards,
> >> Matthias
> > 
> > It's a totally independent HW block instead of a subsystem.
> > I think it's more simple than MMSYS or SCPSYS. But if you would like to
> > understand more about this HW, we could find another way/channel to
> > introduce it.
> > 
> 
> If it's a independent HW block, then we are good. No further information needed 
> by me. I'd just advise to rename the infra_base to something like base, as it 
> made me confuse.
> 
> Thanks!
> Matthias

You can imagine that infra_base means infra devapc base address for
MT6779. In 5G platforms, MediaTek infrastructure would separate into
multiple parts, so does devapc HW. And devapc would be like:
infra_base, peri_base, peri2_base, ...

Thanks.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Neal Liu <neal.liu@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org>,
	wsd_upstream@mediatek.com, devicetree@vger.kernel.org,
	lkml <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	linux-mediatek@lists.infradead.org,
	Neal Liu <neal.liu@mediatek.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 2/2] soc: mediatek: add mt6779 devapc driver
Date: Mon, 12 Oct 2020 11:24:58 +0800	[thread overview]
Message-ID: <1602473098.26774.5.camel@mtkswgap22> (raw)
In-Reply-To: <0ece983b-2e55-cf06-aca8-02a014fce090@gmail.com>

On Fri, 2020-10-09 at 14:34 +0200, Matthias Brugger wrote:
> 
> On 08/10/2020 11:39, Neal Liu wrote:
> > On Thu, 2020-10-08 at 10:45 +0200, Matthias Brugger wrote:
> >>
> >> On 08/10/2020 04:35, Neal Liu wrote:
> >>> On Wed, 2020-10-07 at 12:44 +0200, Matthias Brugger wrote:
> >>>>
> >>>> On 27/08/2020 05:06, Neal Liu wrote:
> [...]
> 
> >>>>> +static int mtk_devapc_probe(struct platform_device *pdev)
> >>>>> +{
> >>>>> +	struct device_node *node = pdev->dev.of_node;
> >>>>> +	struct mtk_devapc_context *ctx;
> >>>>> +	u32 devapc_irq;
> >>>>> +	int ret;
> >>>>> +
> >>>>> +	if (IS_ERR(node))
> >>>>> +		return -ENODEV;
> >>>>> +
> >>>>> +	ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
> >>>>> +	if (!ctx)
> >>>>> +		return -ENOMEM;
> >>>>> +
> >>>>> +	ctx->data = of_device_get_match_data(&pdev->dev);
> >>>>> +	ctx->dev = &pdev->dev;
> >>>>> +
> >>>>> +	ctx->infra_base = of_iomap(node, 0);
> >>>>
> >>>> Does this mean the device is part of the infracfg block?
> >>>> I wasn't able to find any information about it.
> >>>
> >>> I'm not sure why you would ask infracfg block. devapc is parts of our
> >>> SoC infra, it's different with infracfg.
> >>>
> >>
> >> I'm asking because I want to understand the HW better. I'm not able to find any
> >> information in the datasheets. I want to avoid a situation as we had with the
> >> MMSYS where a clock driver was submitted first and later on we realized that
> >> MMSYS is much more then that and we had to work hard to get the driver right.
> >>
> >> Now it's happening with SCPSYS, where a driver with the scpsys compatible was
> >> send years ago. But SCPSYS is much more then the driver submitted. In this case
> >> we opted to write a new driver, but moving from one driver to another one is
> >> painfull and full of problems. For that I want to make sure we fully understand
> >> Device APC (by the way, what does APC stands for?). Is it a totally independent
> >> HW block or is it part of a subsystem, like for example SCP?
> >>
> >> Regards,
> >> Matthias
> > 
> > It's a totally independent HW block instead of a subsystem.
> > I think it's more simple than MMSYS or SCPSYS. But if you would like to
> > understand more about this HW, we could find another way/channel to
> > introduce it.
> > 
> 
> If it's a independent HW block, then we are good. No further information needed 
> by me. I'd just advise to rename the infra_base to something like base, as it 
> made me confuse.
> 
> Thanks!
> Matthias

You can imagine that infra_base means infra devapc base address for
MT6779. In 5G platforms, MediaTek infrastructure would separate into
multiple parts, so does devapc HW. And devapc would be like:
infra_base, peri_base, peri2_base, ...

Thanks.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-10-12  3:25 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-27  3:06 [PATCH v7] Add MediaTek MT6779 devapc driver Neal Liu
2020-08-27  3:06 ` Neal Liu
2020-08-27  3:06 ` Neal Liu
2020-08-27  3:06 ` [PATCH v7 1/2] dt-bindings: devapc: add bindings for mtk-devapc Neal Liu
2020-08-27  3:06   ` Neal Liu
2020-08-27  3:06   ` Neal Liu
2020-08-27  3:06 ` [PATCH v7 2/2] soc: mediatek: add mt6779 devapc driver Neal Liu
2020-08-27  3:06   ` Neal Liu
2020-08-27  3:06   ` Neal Liu
2020-10-02 16:24   ` Chun-Kuang Hu
2020-10-02 16:24     ` Chun-Kuang Hu
2020-10-02 16:24     ` Chun-Kuang Hu
2020-10-05  7:20     ` Neal Liu
2020-10-05  7:20       ` Neal Liu
2020-10-05  7:20       ` Neal Liu
2020-10-07 10:44   ` Matthias Brugger
2020-10-07 10:44     ` Matthias Brugger
2020-10-07 10:44     ` Matthias Brugger
2020-10-08  2:35     ` Neal Liu
2020-10-08  2:35       ` Neal Liu
2020-10-08  2:35       ` Neal Liu
2020-10-08  8:45       ` Matthias Brugger
2020-10-08  8:45         ` Matthias Brugger
2020-10-08  8:45         ` Matthias Brugger
2020-10-08  9:39         ` Neal Liu
2020-10-08  9:39           ` Neal Liu
2020-10-08  9:39           ` Neal Liu
2020-10-09 12:34           ` Matthias Brugger
2020-10-09 12:34             ` Matthias Brugger
2020-10-09 12:34             ` Matthias Brugger
2020-10-12  3:24             ` Neal Liu [this message]
2020-10-12  3:24               ` Neal Liu
2020-10-12  3:24               ` Neal Liu
2020-10-15  2:13       ` Neal Liu
2020-10-15  2:13         ` Neal Liu
2020-10-15  2:13         ` Neal Liu
2020-10-15  9:13         ` Matthias Brugger
2020-10-15  9:13           ` Matthias Brugger
2020-10-15  9:13           ` Matthias Brugger
2020-09-02  6:40 ` [PATCH v7] Add MediaTek MT6779 " Neal Liu
2020-09-02  6:40   ` Neal Liu
2020-09-02  6:40   ` Neal Liu
2020-09-09  8:37   ` Neal Liu
2020-09-09  8:37     ` Neal Liu
2020-09-09  8:37     ` Neal Liu
2020-09-16  8:58     ` Neal Liu
2020-09-16  8:58       ` Neal Liu
2020-09-16  8:58       ` Neal Liu
2020-09-22  7:13       ` Neal Liu
2020-09-22  7:13         ` Neal Liu
2020-09-22  7:13         ` Neal Liu
2020-09-30  7:10         ` Neal Liu
2020-09-30  7:10           ` Neal Liu
2020-09-30  7:10           ` Neal Liu
2020-10-02 16:17           ` Chun-Kuang Hu
2020-10-02 16:17             ` Chun-Kuang Hu
2020-10-02 16:17             ` Chun-Kuang Hu

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=1602473098.26774.5.camel@mtkswgap22 \
    --to=neal.liu@mediatek.com \
    --cc=chunkuang.hu@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=wsd_upstream@mediatek.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.