public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Laxman Dewangan <ldewangan@nvidia.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stephen Warren <swarren@nvidia.com>
Subject: Re: [PATCH V2 RESEND 1/2] regmap: irq: Add support for interrupt type
Date: Sat, 16 Mar 2013 20:16:42 +0530	[thread overview]
Message-ID: <514485D2.6000806@nvidia.com> (raw)
In-Reply-To: <20130312195546.GH19942@opensource.wolfsonmicro.com>

On Wednesday 13 March 2013 01:25 AM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Thu, Mar 07, 2013 at 10:03:17PM +0530, Laxman Dewangan wrote:
>
>>   /**
>> + * The Regmap IRQ type Index
>> + * REGMAP_IRQ_TYPE_NONE is used for setting inital value for clearing type.
>> + */
>> +enum {
>> +	REGMAP_IRQ_TYPE_NONE,
>> +	REGMAP_IRQ_TYPE_RISING,
>> +	REGMAP_IRQ_TYPE_FALLING,
>> +	REGMAP_IRQ_TYPE_BOTH,
>> +	REGMAP_IRQ_TYPE_LEVEL_HIGH,
>> +	REGMAP_IRQ_TYPE_LEVEL_LOW,
>> +
>> +	/* Last entry to get maximum index */
>> +	REGMAP_IRQ_TYPE_NR,
> Why can't we just use the normal IRQ_TYPE macros?

IRQ_TYPE is bit wise allocated and I wanted to have on serieal index to 
assign value on array indexed with type.

>
>> + * @type_reg_sub_offset: Suboffset for type register if type mask are
>> + *              accomodated in the multiple register.
>> + * @type_supported_flags: Supported interrupt type as per interrupt.h.
>> + *             All supported flags are ORed.
>> + * type_mask: Type mask for getting related register bits.
>> + * @type_value: The type value in array form to set value for a given flag.
> This is making my head hurt, it's a bit confusing - I'm having to think
> too hard to understand what all these different fields do and how they
> interact.  Especially type_reg_sub_offset which feels like it must be
> part of a wider feature to support a greater range of register layouts.
>
> Can you clarify a bit please?
>

Sorry for complicating the things.
When I added this feature I was working on two PMICs, Max77660/MAX77663 
and the Palmas. I also consider how it is possible to handle in the 
tps65910 but seems not possible.
All this driver uses the regmap-irq. (MAX77660 is not in mainline and 
working on upstreaming this)
On Max77660/Max77663, the interrupt support is having 2 level, one top 
level for main interrupt like GPIO, RTC interrupt and second level in the
sub module like for RTC submodule: alram or timer in RTC interrupt 
mask/status, for GPIO submodule: gpio control and gpio interrupt status.
GPIO sub module of MAX77660/MAX77663 is as follows:
- Top level interrupt for gpio module.
- GPIO  module have GPIOx_CNTRL where bit6:5 shows the rising/falling 
edge interrupt and GPIO_INT_STATUS shows the interrupt status.
GPIO0_CNTL(0x20): bit 6:5: rising/falling edge of gpio0
GPIO1_CNTL(0x21): bit 65:5 rising/falling edge of gpio1
::::::::::::::::::::::::::::
GPIO7_CNTRL(0x27): bit 65:5 rising/falling edge of gpio7

GPIO_INT_STATUS: bit 0 for gpio0, bit 1 for gpio1, bit 2 for gpio2 etc.

There is no separate mask register here.


For palmas: All interrupts are on same level, there is no two level of 
interrupts.
There is 4 interrupt mask/status interrupt.

INT4_MASK/STATUS: bit 0 for gpio0, bit 1 for gpio1, bit 2 for gpio2 etc.
INT4_EDGE1_REG: bit 1:0 for gpio0 rising/falling, bit 3:2 for gpio1 
rising falling...
INT4_EDGE2_REG: bit 1:0 for gpio4 rising/falling, bit 3:2 for gpio5 
rising falling...

It has mask, interrupt status, edge1, edg2 as part of set of register. 
For other interrups also there is same sets but edge1 and edge2 are  
reserved.


To support rising/falling through regmap, I consider above two type of 
register set. Here as we can have more than 2 register for edge 
configuration,
I make register_sub_offset with type_register to address edge1 and edge2 
register.

Now, Palmas series have multiple PMICs and currently I am wokring on 
tps65913 and tps80036.
It is easy to support interrupt through regmap-irq for tps65913 but not 
possible to tps80036.
In tps65913, there is 4 int status/mask sets properly address spaced.
INT1_STATUS 0x0, INT2_STATUS 0x5, INT3_STATUS 0xA, INT4_STATUS 0xF
But tps80036 added few more interrupts and so INT5_STATUS which is not 
at 0x14 but it is at different 0x15 and INT6_STATUS 0x1A.
So using regmap-irq for tps80036 is not possible.


So given above limitation on palma, I think I should not complicate type 
support, only add register_type and drop the register_type_offset, 
typically to support the MAX77660.

let me know your opinion.




  reply	other threads:[~2013-03-16 14:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-07 16:33 [PATCH V2 RESEND 2/2] regmap: irq: do not write mask register if it is not supported Laxman Dewangan
2013-03-07 16:33 ` [PATCH V2 RESEND 1/2] regmap: irq: Add support for interrupt type Laxman Dewangan
2013-03-12 19:55   ` Mark Brown
2013-03-16 14:46     ` Laxman Dewangan [this message]
2013-03-12 19:35 ` [PATCH V2 RESEND 2/2] regmap: irq: do not write mask register if it is not supported Mark Brown

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=514485D2.6000806@nvidia.com \
    --to=ldewangan@nvidia.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=swarren@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox