All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Figa <tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	Tomasz Figa <t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	Girish KS <girishks2000-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 1/4] spi: s3c64xx: modified error interrupt handling and init
Date: Fri, 08 Feb 2013 09:33:08 +0100	[thread overview]
Message-ID: <2723874.KAatFKgahz@flatron> (raw)
In-Reply-To: <CAKrE-KfyGCi_+FozSpGTy0A0VJP=Jq-1SHmvKJU02iJKWHcvLQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Thursday 07 of February 2013 09:46:58 Girish KS wrote:
> On Thu, Feb 7, 2013 at 3:09 AM, Tomasz Figa <t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> > Hi Girish,
> > 
> > On Wednesday 06 of February 2013 12:12:29 Girish KS wrote:
> >> On Wed, Feb 6, 2013 at 2:26 AM, Grant Likely
> >> <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>> 
> > wrote:
> >> > On Tue,  5 Feb 2013 15:09:41 -0800, Girish K S
> > 
> > <girishks2000-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >> The status of the interrupt is available in the status register,
> >> >> so reading the clear pending register and writing back the same
> >> >> value will not actually clear the pending interrupts. This patch
> >> >> modifies the interrupt handler to read the status register and
> >> >> clear the corresponding pending bit in the clear pending register.
> >> >> 
> >> >> Modified the hwInit function to clear all the pending interrupts.
> >> >> 
> >> >> Signed-off-by: Girish K S <ks.giri-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> >> >> ---
> >> >> 
> >> >>  drivers/spi/spi-s3c64xx.c |   41
> >> >>  +++++++++++++++++++++++++---------------- 1 file changed, 25
> >> >>  insertions(+), 16 deletions(-)
> >> >> 
> >> >> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> >> >> index ad93231..b770f88 100644
> >> >> --- a/drivers/spi/spi-s3c64xx.c
> >> >> +++ b/drivers/spi/spi-s3c64xx.c
> >> >> @@ -997,25 +997,30 @@ static irqreturn_t s3c64xx_spi_irq(int irq,
> >> >> void *data)>>
> >> >> 
> >> >>  {
> >> >>  
> >> >>       struct s3c64xx_spi_driver_data *sdd = data;
> >> >>       struct spi_master *spi = sdd->master;
> >> >> 
> >> >> -     unsigned int val;
> >> >> +     unsigned int val, clr = 0;
> >> >> 
> >> >> -     val = readl(sdd->regs + S3C64XX_SPI_PENDING_CLR);
> >> >> +     val = readl(sdd->regs + S3C64XX_SPI_STATUS);
> >> >> 
> >> >> -     val &= S3C64XX_SPI_PND_RX_OVERRUN_CLR |
> >> >> -             S3C64XX_SPI_PND_RX_UNDERRUN_CLR |
> >> >> -             S3C64XX_SPI_PND_TX_OVERRUN_CLR |
> >> >> -             S3C64XX_SPI_PND_TX_UNDERRUN_CLR;
> >> >> -
> >> >> -     writel(val, sdd->regs + S3C64XX_SPI_PENDING_CLR);
> >> >> -
> >> >> -     if (val & S3C64XX_SPI_PND_RX_OVERRUN_CLR)
> >> >> +     if (val & S3C64XX_SPI_ST_RX_OVERRUN_ERR) {
> >> >> +             clr = S3C64XX_SPI_PND_RX_OVERRUN_CLR;
> >> >> 
> >> >>               dev_err(&spi->dev, "RX overrun\n");
> >> >> 
> >> >> -     if (val & S3C64XX_SPI_PND_RX_UNDERRUN_CLR)
> >> >> +     }
> >> >> +     if (val & S3C64XX_SPI_ST_RX_UNDERRUN_ERR) {
> >> >> +             clr |= S3C64XX_SPI_PND_RX_UNDERRUN_CLR;
> >> >> 
> >> >>               dev_err(&spi->dev, "RX underrun\n");
> >> >> 
> >> >> -     if (val & S3C64XX_SPI_PND_TX_OVERRUN_CLR)
> >> >> +     }
> >> >> +     if (val & S3C64XX_SPI_ST_TX_OVERRUN_ERR) {
> >> >> +             clr |= S3C64XX_SPI_PND_TX_OVERRUN_CLR;
> >> >> 
> >> >>               dev_err(&spi->dev, "TX overrun\n");
> >> >> 
> >> >> -     if (val & S3C64XX_SPI_PND_TX_UNDERRUN_CLR)
> >> >> +     }
> >> >> +     if (val & S3C64XX_SPI_ST_TX_UNDERRUN_ERR) {
> >> >> +             clr |= S3C64XX_SPI_PND_TX_UNDERRUN_CLR;
> >> >> 
> >> >>               dev_err(&spi->dev, "TX underrun\n");
> >> >> 
> >> >> +     }
> >> >> +
> >> >> +     /* Clear the pending irq by setting and then clearing it */
> >> >> +     writel(clr, sdd->regs + S3C64XX_SPI_PENDING_CLR);
> >> >> +     writel(clr & ~clr, sdd->regs + S3C64XX_SPI_PENDING_CLR);
> >> > 
> >> > Wait, what?  clr & ~clr == 0   Always.  What are you actually
> >> > trying
> >> > to do here?
> >> 
> >> The user manual says, wirting 1 to the pending clear register clears
> >> the interrupt (its not auto clear to 0). so i need to explicitly
> >> reset
> >> those bits thats what the 2nd write does
> > 
> > I have looked through user's manuals of different Samsung SoCs. All of
> > them said that writing 1 to a bit clears the corresponding interrupt,
> > but none of them contain any note that it must be manually cleared to
> > 0.
> What i meant was the clear pending bit will not clear automatically.
> When I set the
> clear pending bit, it remains set. This is a problem for the next
> interrupt cycle.

How did you check that it does not clear automatically?

> > In addition the expression
> > 
> > clr & ~clr
> > 
> > makes no sense, because it is equal to 0.
> 
> It makes sense, because we are not disturbing the interrupt pending
> bit at position 0, which is a trailing clr bit.

You either seem to misunderstand the problem I'm mentioning or not 
understanding it at all.

If you take a variable named clr, no matter what value it is set to, and 
you AND it with bitwise negation of the same variable, you will get 0.

See on this example:

Bits:     7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
         -------------------------------
Values:   1 | 1 | 0 | 0 | 1 | 0 | 0 | 1
         -------------------------------
Negation: 0 | 0 | 1 | 1 | 0 | 1 | 1 | 0
         -------------------------------
AND:      0 | 0 | 0 | 0 | 0 | 0 | 0 | 0

Now, can you see that (clr & ~clr) is the same as (0)?

Best regards,
Tomasz


------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb

WARNING: multiple messages have this Message-ID (diff)
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/4] spi: s3c64xx: modified error interrupt handling and init
Date: Fri, 08 Feb 2013 09:33:08 +0100	[thread overview]
Message-ID: <2723874.KAatFKgahz@flatron> (raw)
In-Reply-To: <CAKrE-KfyGCi_+FozSpGTy0A0VJP=Jq-1SHmvKJU02iJKWHcvLQ@mail.gmail.com>

On Thursday 07 of February 2013 09:46:58 Girish KS wrote:
> On Thu, Feb 7, 2013 at 3:09 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> > Hi Girish,
> > 
> > On Wednesday 06 of February 2013 12:12:29 Girish KS wrote:
> >> On Wed, Feb 6, 2013 at 2:26 AM, Grant Likely
> >> <grant.likely@secretlab.ca>> 
> > wrote:
> >> > On Tue,  5 Feb 2013 15:09:41 -0800, Girish K S
> > 
> > <girishks2000@gmail.com> wrote:
> >> >> The status of the interrupt is available in the status register,
> >> >> so reading the clear pending register and writing back the same
> >> >> value will not actually clear the pending interrupts. This patch
> >> >> modifies the interrupt handler to read the status register and
> >> >> clear the corresponding pending bit in the clear pending register.
> >> >> 
> >> >> Modified the hwInit function to clear all the pending interrupts.
> >> >> 
> >> >> Signed-off-by: Girish K S <ks.giri@samsung.com>
> >> >> ---
> >> >> 
> >> >>  drivers/spi/spi-s3c64xx.c |   41
> >> >>  +++++++++++++++++++++++++---------------- 1 file changed, 25
> >> >>  insertions(+), 16 deletions(-)
> >> >> 
> >> >> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> >> >> index ad93231..b770f88 100644
> >> >> --- a/drivers/spi/spi-s3c64xx.c
> >> >> +++ b/drivers/spi/spi-s3c64xx.c
> >> >> @@ -997,25 +997,30 @@ static irqreturn_t s3c64xx_spi_irq(int irq,
> >> >> void *data)>>
> >> >> 
> >> >>  {
> >> >>  
> >> >>       struct s3c64xx_spi_driver_data *sdd = data;
> >> >>       struct spi_master *spi = sdd->master;
> >> >> 
> >> >> -     unsigned int val;
> >> >> +     unsigned int val, clr = 0;
> >> >> 
> >> >> -     val = readl(sdd->regs + S3C64XX_SPI_PENDING_CLR);
> >> >> +     val = readl(sdd->regs + S3C64XX_SPI_STATUS);
> >> >> 
> >> >> -     val &= S3C64XX_SPI_PND_RX_OVERRUN_CLR |
> >> >> -             S3C64XX_SPI_PND_RX_UNDERRUN_CLR |
> >> >> -             S3C64XX_SPI_PND_TX_OVERRUN_CLR |
> >> >> -             S3C64XX_SPI_PND_TX_UNDERRUN_CLR;
> >> >> -
> >> >> -     writel(val, sdd->regs + S3C64XX_SPI_PENDING_CLR);
> >> >> -
> >> >> -     if (val & S3C64XX_SPI_PND_RX_OVERRUN_CLR)
> >> >> +     if (val & S3C64XX_SPI_ST_RX_OVERRUN_ERR) {
> >> >> +             clr = S3C64XX_SPI_PND_RX_OVERRUN_CLR;
> >> >> 
> >> >>               dev_err(&spi->dev, "RX overrun\n");
> >> >> 
> >> >> -     if (val & S3C64XX_SPI_PND_RX_UNDERRUN_CLR)
> >> >> +     }
> >> >> +     if (val & S3C64XX_SPI_ST_RX_UNDERRUN_ERR) {
> >> >> +             clr |= S3C64XX_SPI_PND_RX_UNDERRUN_CLR;
> >> >> 
> >> >>               dev_err(&spi->dev, "RX underrun\n");
> >> >> 
> >> >> -     if (val & S3C64XX_SPI_PND_TX_OVERRUN_CLR)
> >> >> +     }
> >> >> +     if (val & S3C64XX_SPI_ST_TX_OVERRUN_ERR) {
> >> >> +             clr |= S3C64XX_SPI_PND_TX_OVERRUN_CLR;
> >> >> 
> >> >>               dev_err(&spi->dev, "TX overrun\n");
> >> >> 
> >> >> -     if (val & S3C64XX_SPI_PND_TX_UNDERRUN_CLR)
> >> >> +     }
> >> >> +     if (val & S3C64XX_SPI_ST_TX_UNDERRUN_ERR) {
> >> >> +             clr |= S3C64XX_SPI_PND_TX_UNDERRUN_CLR;
> >> >> 
> >> >>               dev_err(&spi->dev, "TX underrun\n");
> >> >> 
> >> >> +     }
> >> >> +
> >> >> +     /* Clear the pending irq by setting and then clearing it */
> >> >> +     writel(clr, sdd->regs + S3C64XX_SPI_PENDING_CLR);
> >> >> +     writel(clr & ~clr, sdd->regs + S3C64XX_SPI_PENDING_CLR);
> >> > 
> >> > Wait, what?  clr & ~clr == 0   Always.  What are you actually
> >> > trying
> >> > to do here?
> >> 
> >> The user manual says, wirting 1 to the pending clear register clears
> >> the interrupt (its not auto clear to 0). so i need to explicitly
> >> reset
> >> those bits thats what the 2nd write does
> > 
> > I have looked through user's manuals of different Samsung SoCs. All of
> > them said that writing 1 to a bit clears the corresponding interrupt,
> > but none of them contain any note that it must be manually cleared to
> > 0.
> What i meant was the clear pending bit will not clear automatically.
> When I set the
> clear pending bit, it remains set. This is a problem for the next
> interrupt cycle.

How did you check that it does not clear automatically?

> > In addition the expression
> > 
> > clr & ~clr
> > 
> > makes no sense, because it is equal to 0.
> 
> It makes sense, because we are not disturbing the interrupt pending
> bit at position 0, which is a trailing clr bit.

You either seem to misunderstand the problem I'm mentioning or not 
understanding it at all.

If you take a variable named clr, no matter what value it is set to, and 
you AND it with bitwise negation of the same variable, you will get 0.

See on this example:

Bits:     7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
         -------------------------------
Values:   1 | 1 | 0 | 0 | 1 | 0 | 0 | 1
         -------------------------------
Negation: 0 | 0 | 1 | 1 | 0 | 1 | 1 | 0
         -------------------------------
AND:      0 | 0 | 0 | 0 | 0 | 0 | 0 | 0

Now, can you see that (clr & ~clr) is the same as (0)?

Best regards,
Tomasz

WARNING: multiple messages have this Message-ID (diff)
From: Tomasz Figa <tomasz.figa@gmail.com>
To: linux-arm-kernel@lists.infradead.org
Cc: Girish KS <girishks2000@gmail.com>,
	Tomasz Figa <t.figa@samsung.com>,
	Grant Likely <grant.likely@secretlab.ca>,
	spi-devel-general@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] spi: s3c64xx: modified error interrupt handling and init
Date: Fri, 08 Feb 2013 09:33:08 +0100	[thread overview]
Message-ID: <2723874.KAatFKgahz@flatron> (raw)
In-Reply-To: <CAKrE-KfyGCi_+FozSpGTy0A0VJP=Jq-1SHmvKJU02iJKWHcvLQ@mail.gmail.com>

On Thursday 07 of February 2013 09:46:58 Girish KS wrote:
> On Thu, Feb 7, 2013 at 3:09 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> > Hi Girish,
> > 
> > On Wednesday 06 of February 2013 12:12:29 Girish KS wrote:
> >> On Wed, Feb 6, 2013 at 2:26 AM, Grant Likely
> >> <grant.likely@secretlab.ca>> 
> > wrote:
> >> > On Tue,  5 Feb 2013 15:09:41 -0800, Girish K S
> > 
> > <girishks2000@gmail.com> wrote:
> >> >> The status of the interrupt is available in the status register,
> >> >> so reading the clear pending register and writing back the same
> >> >> value will not actually clear the pending interrupts. This patch
> >> >> modifies the interrupt handler to read the status register and
> >> >> clear the corresponding pending bit in the clear pending register.
> >> >> 
> >> >> Modified the hwInit function to clear all the pending interrupts.
> >> >> 
> >> >> Signed-off-by: Girish K S <ks.giri@samsung.com>
> >> >> ---
> >> >> 
> >> >>  drivers/spi/spi-s3c64xx.c |   41
> >> >>  +++++++++++++++++++++++++---------------- 1 file changed, 25
> >> >>  insertions(+), 16 deletions(-)
> >> >> 
> >> >> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> >> >> index ad93231..b770f88 100644
> >> >> --- a/drivers/spi/spi-s3c64xx.c
> >> >> +++ b/drivers/spi/spi-s3c64xx.c
> >> >> @@ -997,25 +997,30 @@ static irqreturn_t s3c64xx_spi_irq(int irq,
> >> >> void *data)>>
> >> >> 
> >> >>  {
> >> >>  
> >> >>       struct s3c64xx_spi_driver_data *sdd = data;
> >> >>       struct spi_master *spi = sdd->master;
> >> >> 
> >> >> -     unsigned int val;
> >> >> +     unsigned int val, clr = 0;
> >> >> 
> >> >> -     val = readl(sdd->regs + S3C64XX_SPI_PENDING_CLR);
> >> >> +     val = readl(sdd->regs + S3C64XX_SPI_STATUS);
> >> >> 
> >> >> -     val &= S3C64XX_SPI_PND_RX_OVERRUN_CLR |
> >> >> -             S3C64XX_SPI_PND_RX_UNDERRUN_CLR |
> >> >> -             S3C64XX_SPI_PND_TX_OVERRUN_CLR |
> >> >> -             S3C64XX_SPI_PND_TX_UNDERRUN_CLR;
> >> >> -
> >> >> -     writel(val, sdd->regs + S3C64XX_SPI_PENDING_CLR);
> >> >> -
> >> >> -     if (val & S3C64XX_SPI_PND_RX_OVERRUN_CLR)
> >> >> +     if (val & S3C64XX_SPI_ST_RX_OVERRUN_ERR) {
> >> >> +             clr = S3C64XX_SPI_PND_RX_OVERRUN_CLR;
> >> >> 
> >> >>               dev_err(&spi->dev, "RX overrun\n");
> >> >> 
> >> >> -     if (val & S3C64XX_SPI_PND_RX_UNDERRUN_CLR)
> >> >> +     }
> >> >> +     if (val & S3C64XX_SPI_ST_RX_UNDERRUN_ERR) {
> >> >> +             clr |= S3C64XX_SPI_PND_RX_UNDERRUN_CLR;
> >> >> 
> >> >>               dev_err(&spi->dev, "RX underrun\n");
> >> >> 
> >> >> -     if (val & S3C64XX_SPI_PND_TX_OVERRUN_CLR)
> >> >> +     }
> >> >> +     if (val & S3C64XX_SPI_ST_TX_OVERRUN_ERR) {
> >> >> +             clr |= S3C64XX_SPI_PND_TX_OVERRUN_CLR;
> >> >> 
> >> >>               dev_err(&spi->dev, "TX overrun\n");
> >> >> 
> >> >> -     if (val & S3C64XX_SPI_PND_TX_UNDERRUN_CLR)
> >> >> +     }
> >> >> +     if (val & S3C64XX_SPI_ST_TX_UNDERRUN_ERR) {
> >> >> +             clr |= S3C64XX_SPI_PND_TX_UNDERRUN_CLR;
> >> >> 
> >> >>               dev_err(&spi->dev, "TX underrun\n");
> >> >> 
> >> >> +     }
> >> >> +
> >> >> +     /* Clear the pending irq by setting and then clearing it */
> >> >> +     writel(clr, sdd->regs + S3C64XX_SPI_PENDING_CLR);
> >> >> +     writel(clr & ~clr, sdd->regs + S3C64XX_SPI_PENDING_CLR);
> >> > 
> >> > Wait, what?  clr & ~clr == 0   Always.  What are you actually
> >> > trying
> >> > to do here?
> >> 
> >> The user manual says, wirting 1 to the pending clear register clears
> >> the interrupt (its not auto clear to 0). so i need to explicitly
> >> reset
> >> those bits thats what the 2nd write does
> > 
> > I have looked through user's manuals of different Samsung SoCs. All of
> > them said that writing 1 to a bit clears the corresponding interrupt,
> > but none of them contain any note that it must be manually cleared to
> > 0.
> What i meant was the clear pending bit will not clear automatically.
> When I set the
> clear pending bit, it remains set. This is a problem for the next
> interrupt cycle.

How did you check that it does not clear automatically?

> > In addition the expression
> > 
> > clr & ~clr
> > 
> > makes no sense, because it is equal to 0.
> 
> It makes sense, because we are not disturbing the interrupt pending
> bit at position 0, which is a trailing clr bit.

You either seem to misunderstand the problem I'm mentioning or not 
understanding it at all.

If you take a variable named clr, no matter what value it is set to, and 
you AND it with bitwise negation of the same variable, you will get 0.

See on this example:

Bits:     7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
         -------------------------------
Values:   1 | 1 | 0 | 0 | 1 | 0 | 0 | 1
         -------------------------------
Negation: 0 | 0 | 1 | 1 | 0 | 1 | 1 | 0
         -------------------------------
AND:      0 | 0 | 0 | 0 | 0 | 0 | 0 | 0

Now, can you see that (clr & ~clr) is the same as (0)?

Best regards,
Tomasz


  parent reply	other threads:[~2013-02-08  8:33 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-05 23:09 [PATCH 0/4] Add polling support for 64xx spi controller Girish K S
2013-02-05 23:09 ` Girish K S
2013-02-05 23:09 ` Girish K S
     [not found] ` <1360105784-12282-1-git-send-email-ks.giri-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2013-02-05 23:09   ` [PATCH 1/4] spi: s3c64xx: modified error interrupt handling and init Girish K S
2013-02-05 23:09     ` Girish K S
2013-02-05 23:09     ` Girish K S
     [not found]     ` <1360105784-12282-2-git-send-email-ks.giri-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2013-02-06 10:26       ` Grant Likely
2013-02-06 10:26         ` Grant Likely
2013-02-06 10:26         ` Grant Likely
2013-02-06 20:12         ` Girish KS
2013-02-06 20:12           ` Girish KS
2013-02-06 20:12           ` Girish KS
     [not found]           ` <CAKrE-KdX+Nxk0X4xdz6Dx3WVtOpV+ms+gPB-Dq-MwZwetyZ5Nw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-06 23:48             ` Grant Likely
2013-02-06 23:48               ` Grant Likely
2013-02-06 23:48               ` Grant Likely
     [not found]               ` <CACxGe6uOaoRbtuovEsA87d-MtCbGNd3KZCeHXbBQaEpp6NZ7fA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-07  0:33                 ` Girish KS
2013-02-07  0:33                   ` Girish KS
2013-02-07  0:33                   ` Girish KS
2013-02-08  1:04                 ` Girish KS
2013-02-08  1:04                   ` Girish KS
2013-02-08  1:04                   ` Girish KS
     [not found]                   ` <CAKrE-KfvywLa4xTwCGzan9OfevzBdY8Z2EO2Mc2VaFm5y0XEzg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-08  8:16                     ` Girish KS
2013-02-08  8:16                       ` Girish KS
2013-02-08  8:16                       ` Girish KS
2013-02-07 11:09           ` Tomasz Figa
2013-02-07 11:09             ` Tomasz Figa
2013-02-07 17:46             ` Girish KS
2013-02-07 17:46               ` Girish KS
2013-02-07 17:46               ` Girish KS
     [not found]               ` <CAKrE-KfyGCi_+FozSpGTy0A0VJP=Jq-1SHmvKJU02iJKWHcvLQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-08  8:33                 ` Tomasz Figa [this message]
2013-02-08  8:33                   ` Tomasz Figa
2013-02-08  8:33                   ` Tomasz Figa
2013-02-08  8:58                   ` Girish KS
2013-02-08  8:58                     ` Girish KS
2013-02-08  8:58                     ` Girish KS
     [not found]                     ` <CAKrE-Kd-mNv=_YkM7GjicgDx=0hqbp5B6qwEvcRzhuSibRNaZA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-08  9:26                       ` Girish KS
2013-02-08  9:26                         ` Girish KS
2013-02-08  9:26                         ` Girish KS
2013-02-05 23:09   ` [PATCH 3/4] spi: s3c64xx: add gpio quirk for controller Girish K S
2013-02-05 23:09     ` Girish K S
2013-02-05 23:09     ` Girish K S
     [not found]     ` <1360105784-12282-4-git-send-email-ks.giri-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2013-02-06 10:40       ` Grant Likely
2013-02-06 10:40         ` Grant Likely
2013-02-06 10:40         ` Grant Likely
2013-02-06 22:38         ` Girish KS
2013-02-06 22:38           ` Girish KS
2013-02-06 22:38           ` Girish KS
2013-02-07 11:55       ` Mark Brown
2013-02-07 11:55         ` Mark Brown
2013-02-07 11:55         ` Mark Brown
     [not found]         ` <20130207115546.GA3801-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-02-07 18:54           ` Girish KS
2013-02-07 18:54             ` Girish KS
2013-02-07 18:54             ` Girish KS
2013-02-08 13:17             ` Mark Brown
2013-02-08 13:17               ` Mark Brown
2013-02-05 23:09   ` [PATCH 4/4] spi: s3c64xx: add support for exynos5440 spi Girish K S
2013-02-05 23:09     ` Girish K S
2013-02-05 23:09     ` Girish K S
2013-02-05 23:09 ` [PATCH 2/4] spi: s3c64xx: added support for polling mode Girish K S
2013-02-05 23:09   ` Girish K S
     [not found]   ` <1360105784-12282-3-git-send-email-ks.giri-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2013-02-06 10:35     ` Grant Likely
2013-02-06 10:35       ` Grant Likely
2013-02-06 10:35       ` Grant Likely
2013-02-06 22:04       ` Girish KS
2013-02-06 22:04         ` Girish KS
2013-02-06 22:04         ` Girish KS

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=2723874.KAatFKgahz@flatron \
    --to=tomasz.figa-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=girishks2000-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=t.figa-Sze3O3UU22JBDgjK7y7TUQ@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 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.