From: Michael Welling <mwelling@ieee.org>
To: Mark Brown <broonie@kernel.org>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-next@vger.kernel.org, linux-spi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] spi: omap2-mcspi: Fix native cs with new set_cs
Date: Fri, 22 May 2015 10:31:57 -0500 [thread overview]
Message-ID: <20150522153157.GA12285@deathray> (raw)
In-Reply-To: <20150522122544.GL21391@sirena.org.uk>
On Fri, May 22, 2015 at 01:25:44PM +0100, Mark Brown wrote:
> On Thu, May 21, 2015 at 06:48:33PM -0500, Michael Welling wrote:
>
> > So after reverting this patch I found there is a issue in that it is difficult
> > to determine when a transfer is complete to properly drive the chipselect from
> > within the transfer_one function.
>
> Is unprepare_message() a suitable place here? I've got a feeling the
> answer is no...
>
> > Then I figured that we could handle the case when GPIOs are being used with
> > some conditional calls to omap2_mcspi_set_cs in the omap2_mcspi_work_one
> > function.
> >
> > Near the beginning of the function I added:
> > if (gpio_is_valid(spi->cs_gpio))
> > omap2_mcspi_set_cs(spi, 0);
> >
> > Near the end of the function I added:
> > if (gpio_is_valid(spi->cs_gpio))
> > omap2_mcspi_set_cs(spi, 1);
> >
> > This makes GPIO chip select support work while leaving the native working
> > as previous.
> >
> > Is this solution acceptible?
>
> I think that's probably OK as well, it's not ideal though (and risky if
> the chip select is routed somewhere...).
>
> > In the process of reviewing the changes I found a few other things that
> > should be changed as well.
>
> Please send fixes for these as separate patches (ideally without any
> dependency on your new work so we can send them to Linus as fixes).
>
Well actually these fixes are needed as the results of the first three patches
pushed into next.
When switching from transfer_one_message to tranfer_one I did not realize that
the delay was handled in the core.
When adding the set_cs function I did not notice that the enable was
complemented by the core driver.
> > Here you will see a delay that is already handled by the core spi driver:
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/spi/spi-omap2-mcspi.c#n1166
>
> I can't actually see that since I have no internet access right now!
That's like a fish out of water.
WARNING: multiple messages have this Message-ID (diff)
From: mwelling@ieee.org (Michael Welling)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] spi: omap2-mcspi: Fix native cs with new set_cs
Date: Fri, 22 May 2015 10:31:57 -0500 [thread overview]
Message-ID: <20150522153157.GA12285@deathray> (raw)
In-Reply-To: <20150522122544.GL21391@sirena.org.uk>
On Fri, May 22, 2015 at 01:25:44PM +0100, Mark Brown wrote:
> On Thu, May 21, 2015 at 06:48:33PM -0500, Michael Welling wrote:
>
> > So after reverting this patch I found there is a issue in that it is difficult
> > to determine when a transfer is complete to properly drive the chipselect from
> > within the transfer_one function.
>
> Is unprepare_message() a suitable place here? I've got a feeling the
> answer is no...
>
> > Then I figured that we could handle the case when GPIOs are being used with
> > some conditional calls to omap2_mcspi_set_cs in the omap2_mcspi_work_one
> > function.
> >
> > Near the beginning of the function I added:
> > if (gpio_is_valid(spi->cs_gpio))
> > omap2_mcspi_set_cs(spi, 0);
> >
> > Near the end of the function I added:
> > if (gpio_is_valid(spi->cs_gpio))
> > omap2_mcspi_set_cs(spi, 1);
> >
> > This makes GPIO chip select support work while leaving the native working
> > as previous.
> >
> > Is this solution acceptible?
>
> I think that's probably OK as well, it's not ideal though (and risky if
> the chip select is routed somewhere...).
>
> > In the process of reviewing the changes I found a few other things that
> > should be changed as well.
>
> Please send fixes for these as separate patches (ideally without any
> dependency on your new work so we can send them to Linus as fixes).
>
Well actually these fixes are needed as the results of the first three patches
pushed into next.
When switching from transfer_one_message to tranfer_one I did not realize that
the delay was handled in the core.
When adding the set_cs function I did not notice that the enable was
complemented by the core driver.
> > Here you will see a delay that is already handled by the core spi driver:
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/spi/spi-omap2-mcspi.c#n1166
>
> I can't actually see that since I have no internet access right now!
That's like a fish out of water.
next prev parent reply other threads:[~2015-05-22 15:31 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-12 17:38 [PATCH] spi: omap2-mcspi: Fix native cs with new set_cs Michael Welling
2015-05-12 17:38 ` Michael Welling
2015-05-12 18:57 ` Nishanth Menon
2015-05-12 18:57 ` Nishanth Menon
2015-05-12 18:57 ` Nishanth Menon
[not found] ` <55524D20.2050203-l0cyMroinI0@public.gmane.org>
2015-05-12 19:19 ` Mark Brown
2015-05-12 19:19 ` Mark Brown
2015-05-12 19:19 ` Mark Brown
2015-05-12 19:21 ` Nishanth Menon
2015-05-12 19:21 ` Nishanth Menon
2015-05-12 19:21 ` Nishanth Menon
2015-05-12 19:17 ` Mark Brown
2015-05-12 19:17 ` Mark Brown
[not found] ` <20150512191758.GX3066-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2015-05-21 2:07 ` Michael Welling
2015-05-21 2:07 ` Michael Welling
2015-05-21 2:07 ` Michael Welling
2015-05-21 10:18 ` Mark Brown
2015-05-21 10:18 ` Mark Brown
2015-05-21 21:04 ` Michael Welling
2015-05-21 21:04 ` Michael Welling
2015-05-21 21:16 ` Mark Brown
2015-05-21 21:16 ` Mark Brown
2015-05-21 23:48 ` Michael Welling
2015-05-21 23:48 ` Michael Welling
2015-05-22 12:25 ` Mark Brown
2015-05-22 12:25 ` Mark Brown
2015-05-22 12:25 ` Mark Brown
2015-05-22 15:31 ` Michael Welling [this message]
2015-05-22 15:31 ` Michael Welling
2015-05-24 2:13 ` [PATCH 0/4] spi: omap2-mcspi: Fixes for recent updates Michael Welling
2015-05-24 2:13 ` Michael Welling
2015-05-24 2:13 ` [PATCH 1/4] spi: omap2-mcspi: Remove unnecessary delay Michael Welling
2015-05-24 2:13 ` Michael Welling
2015-05-24 2:13 ` [PATCH 2/4] spi: omap2-mcspi: Fix set_cs function for active high Michael Welling
2015-05-24 2:13 ` Michael Welling
2015-05-24 2:13 ` [PATCH 3/4] spi: omap2-mcspi: Fix GPIO chip select support Michael Welling
2015-05-24 2:13 ` Michael Welling
2015-05-24 2:13 ` [PATCH 4/4] spi: omap2-mcspi: Handle error on gpio_request Michael Welling
2015-05-24 2:13 ` Michael Welling
2015-05-24 8:13 ` Nicholas Mc Guire
2015-05-24 8:13 ` Nicholas Mc Guire
2015-05-24 16:52 ` Michael Welling
2015-05-24 16:52 ` Michael Welling
[not found] ` <1432433625-23407-1-git-send-email-mwelling-EkmVulN54Sk@public.gmane.org>
2015-05-25 12:00 ` [PATCH 0/4] spi: omap2-mcspi: Fixes for recent updates Mark Brown
2015-05-25 12:00 ` Mark Brown
2015-05-25 12:00 ` 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=20150522153157.GA12285@deathray \
--to=mwelling@ieee.org \
--cc=broonie@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-spi@vger.kernel.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.