devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mars Cheng <mars.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
To: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	CC Hwang <cc.hwang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	wsd_upstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
	Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
	Loda Chou <loda.chou-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Jades Shih <jades.shih-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Miles Chen <miles.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	My Chuang <my.chuang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	Matthias Brugger
	<matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Yingjoe Chen
	<yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Chieh-Jay Liu
	<Chieh-Jay.Liu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Subject: Re: [PATCH v2 02/10] irqchip: mtk-sysirq: extend intpol base to arbitrary number
Date: Thu, 9 Feb 2017 17:49:06 +0800	[thread overview]
Message-ID: <1486633746.8348.16.camel@mtkswgap22> (raw)
In-Reply-To: <504b27fa-412b-8f21-d9c3-5e2c7dc67dd5-5wv7dgnIgG8@public.gmane.org>

On Thu, 2017-02-09 at 09:43 +0000, Marc Zyngier wrote:
> On 09/02/17 09:31, Mars Cheng wrote:
> > On Thu, 2017-02-09 at 09:03 +0000, Marc Zyngier wrote:
> >> On 06/02/17 12:15, Mars Cheng wrote:
> >>> Originally driver only supports one base. However, MT6797 has
> >>> more than one bases to configure interrupt polarity. To support
> >>> possible design change, here comes a solution to use arbitrary
> >>> number of bases.
> >>>
> >>> Signed-off-by: Mars Cheng <mars.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >>> ---
> >>>  drivers/irqchip/irq-mtk-sysirq.c |   71 +++++++++++++++++++++++++++-----------
> >>>  1 file changed, 50 insertions(+), 21 deletions(-)
> >>>
> >>> diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c
> >>> index 63ac73b..2645706 100644
> >>> --- a/drivers/irqchip/irq-mtk-sysirq.c
> >>> +++ b/drivers/irqchip/irq-mtk-sysirq.c
> >>> @@ -24,7 +24,9 @@
> >>>  
> >>>  struct mtk_sysirq_chip_data {
> >>>  	spinlock_t lock;
> >>> -	void __iomem *intpol_base;
> >>> +	u32 nr_intpol_bases;
> >>> +	void __iomem **intpol_bases;
> >>> +	u32 *intpol_words;
> >>>  };
> >>>  
> >>>  static int mtk_sysirq_set_type(struct irq_data *data, unsigned int type)
> >>> @@ -33,13 +35,15 @@ static int mtk_sysirq_set_type(struct irq_data *data, unsigned int type)
> >>>  	struct mtk_sysirq_chip_data *chip_data = data->chip_data;
> >>>  	u32 offset, reg_index, value;
> >>>  	unsigned long flags;
> >>> -	int ret;
> >>> +	int ret, i;
> >>>  
> >>>  	offset = hwirq & 0x1f;
> >>>  	reg_index = hwirq >> 5;
> >>> +	for (i = 0; reg_index >= chip_data->intpol_words[i]; i++)
> >>> +		reg_index -= chip_data->intpol_words[i];
> >>
> >> Two questions:
> >> - What guarantees that two successive regions deal with consecutive
> >> interrupts? For example, if I have region A that deals with interrupts
> >> 0-31, what guarantees that region B covers 32-63?
> > 
> > It is guaranteed by mediatek's chip design team. For those chips with
> > multiple bases, they all have the consecutive interrupts in the next
> > region.
> 
> Hum. OK. We'll see how long this holds true, I suppose.
> 
> > 
> >> - Given that there is a static relation between a region and a hwirq,
> >> can't you compute this relation at init time, and let set_type be a fast
> >> path?
> >>
> > 
> > sure, I can do this to optimize set_type. will do it in v3
> > 
> >>>  
> >>>  	spin_lock_irqsave(&chip_data->lock, flags);
> >>> -	value = readl_relaxed(chip_data->intpol_base + reg_index * 4);
> >>> +	value = readl_relaxed(chip_data->intpol_bases[i] + reg_index * 4);
> >>>  	if (type == IRQ_TYPE_LEVEL_LOW || type == IRQ_TYPE_EDGE_FALLING) {
> >>>  		if (type == IRQ_TYPE_LEVEL_LOW)
> >>>  			type = IRQ_TYPE_LEVEL_HIGH;
> >>> @@ -49,7 +53,8 @@ static int mtk_sysirq_set_type(struct irq_data *data, unsigned int type)
> >>>  	} else {
> >>>  		value &= ~(1 << offset);
> >>>  	}
> >>> -	writel(value, chip_data->intpol_base + reg_index * 4);
> >>> +
> >>> +	writel(value, chip_data->intpol_bases[i] + reg_index * 4);
> >>
> >> Why do you have a writel here, while you're using relaxed accessors
> >> otherwise? Is there anything else that needs to be made visible to the
> >> irqchip?
> >>
> > 
> > before we call spin_unlock_irqrestore() in the end of set_type, polarity
> > should take effect so we use writel() here. This patch did not change
> > the usage.
> 
> That's not what I mean. writel has a DSB *before* performing the write
> to the device. Do you have any write (to memory) that needs to be made
> visible to the irqchip before the write to the register occurs?
> 
> Looking at the code, I'd say no. This is a standard device
> read-modify-write sequence, no in-memory data that needs to make it
> before the write occurs.
> 
> So please turn this into a writel_relaxed.

Got it, you are right. will fix this in v3.

> 
> > 
> >>>  
> >>>  	data = data->parent_data;
> >>>  	ret = data->chip->irq_set_type(data, type);
> >>> @@ -124,8 +129,7 @@ static int __init mtk_sysirq_of_init(struct device_node *node,
> >>>  {
> >>>  	struct irq_domain *domain, *domain_parent;
> >>>  	struct mtk_sysirq_chip_data *chip_data;
> >>> -	int ret, size, intpol_num;
> >>> -	struct resource res;
> >>> +	int ret, size, intpol_num = 0, nr_intpol_bases, i;
> >>>  
> >>>  	domain_parent = irq_find_host(parent);
> >>>  	if (!domain_parent) {
> >>> @@ -133,36 +137,61 @@ static int __init mtk_sysirq_of_init(struct device_node *node,
> >>>  		return -EINVAL;
> >>>  	}
> >>>  
> >>> -	ret = of_address_to_resource(node, 0, &res);
> >>> -	if (ret)
> >>> -		return ret;
> >>> -
> >>>  	chip_data = kzalloc(sizeof(*chip_data), GFP_KERNEL);
> >>>  	if (!chip_data)
> >>>  		return -ENOMEM;
> >>>  
> >>> -	size = resource_size(&res);
> >>> -	intpol_num = size * 8;
> >>> -	chip_data->intpol_base = ioremap(res.start, size);
> >>> -	if (!chip_data->intpol_base) {
> >>> -		pr_err("mtk_sysirq: unable to map sysirq register\n");
> >>> -		ret = -ENXIO;
> >>> -		goto out_free;
> >>> +	if (of_property_read_u32(node, "#intpol-bases", &nr_intpol_bases))
> >>> +		nr_intpol_bases = 1;
> >>> +
> >>> +	chip_data->intpol_words =
> >>> +		kcalloc(nr_intpol_bases, sizeof(u32), GFP_KERNEL);
> >>
> >> Please keep the assignment on a single line.
> >>
> > 
> > Got it, but another warning (prefer 75 char in single line) would pop
> > up. Would you still like me to keep it on a single line?
> 
> rm scripts/checkpatch.pl
> 
> Look, no warning! More seriously, if you're really worried about this,
> you can reformat it:
> 
> 	chip_data->intpol_words = kcalloc(nr_intpol_bases,
> 					  sizeof(u32), GFP_KERNEL);
> 
> like this.
> 

Got it, will fix it in v3. Thanks. :-)

> Thanks,
> 
> 	M.

  parent reply	other threads:[~2017-02-09  9:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-06 12:15 [PATCH v2 00/10] Add Basic SoC support for MT6797 Mars Cheng
2017-02-06 12:15 ` [PATCH v2 01/10] Document: DT: mediatek: multiple base address support for sysirq Mars Cheng
2017-02-08 23:20   ` Rob Herring
2017-02-09  1:47     ` Mars Cheng
2017-02-06 12:15 ` [PATCH v2 05/10] dt-bindings: arm: mediatek: document clk bindings for MT6797 Mars Cheng
     [not found]   ` <1486383336-16892-6-git-send-email-mars.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2017-02-09  0:35     ` Rob Herring
2017-02-06 12:15 ` [PATCH v2 06/10] clk: mediatek: add clk support " Mars Cheng
2017-02-11 23:31   ` Matthias Brugger
2017-02-06 12:15 ` [PATCH v2 08/10] soc: mediatek: add MT6797 power dt-bindings Mars Cheng
2017-02-09  0:37   ` Rob Herring
2017-02-09  1:32     ` Mars Cheng
2017-02-06 12:15 ` [PATCH v2 09/10] soc: mediatek: add MT6797 scysys support Mars Cheng
     [not found] ` <1486383336-16892-1-git-send-email-mars.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2017-02-06 12:15   ` [PATCH v2 02/10] irqchip: mtk-sysirq: extend intpol base to arbitrary number Mars Cheng
     [not found]     ` <1486383336-16892-3-git-send-email-mars.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2017-02-09  9:03       ` Marc Zyngier
     [not found]         ` <2079ad73-6d7d-d20f-2945-68ea9fbd9b50-5wv7dgnIgG8@public.gmane.org>
2017-02-09  9:31           ` Mars Cheng
2017-02-09  9:43             ` Marc Zyngier
     [not found]               ` <504b27fa-412b-8f21-d9c3-5e2c7dc67dd5-5wv7dgnIgG8@public.gmane.org>
2017-02-09  9:49                 ` Mars Cheng [this message]
2017-02-06 12:15   ` [PATCH v2 03/10] Document: DT: Add bindings for mediatek MT6797 SoC Platform Mars Cheng
2017-02-09  0:34     ` Rob Herring
2017-02-06 12:15   ` [PATCH v2 04/10] arm64: dts: mediatek: add mt6797 support Mars Cheng
2017-02-06 12:28     ` Marc Zyngier
2017-02-06 12:37       ` Mars Cheng
2017-02-06 12:15   ` [PATCH v2 07/10] soc: mediatek: refine scysys for mediatek platforms Mars Cheng
2017-02-11 23:15     ` Matthias Brugger
2017-02-06 12:15   ` [PATCH v2 10/10] arm64: dts: mediatek: add clk nodes for MT6797 Mars Cheng

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=1486633746.8348.16.camel@mtkswgap22 \
    --to=mars.cheng-nus5lvnupcjwk0htik3j/w@public.gmane.org \
    --cc=Chieh-Jay.Liu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
    --cc=cc.hwang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=jades.shih-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
    --cc=linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=loda.chou-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
    --cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
    --cc=matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=miles.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
    --cc=my.chuang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
    --cc=sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
    --cc=wsd_upstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
    --cc=yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
    /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).