| Message ID | 1445009343-28307-1-git-send-email-fcooper@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Oct 16, 2015 at 6:29 PM, Franklin S Cooper Jr <fcooper@ti.com> wrote: > SPI controllers may need to be properly setup before chip selects > can be used. Therefore, wait until the spi controller has a chance > to perform their setup procedure before trying to use the chip > select. > > This also insures that the chip selects pins are in a good > state before asseting them which otherwise may cause confusion. > > Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> Does it mean I have to test it again? > --- > Keystone 2 devices currently fail to boot in linux-next after the > below commit was applied: > > spi: bitbang: switch to the generic implementation of transfer_one_message > commit: 0037686596832572bbca05ab168d9884d7d704c1 > > This patch allows Keystone 2 devices to boot again in linux-next. > > Tested this patch on K2E evm and am437 starterkit which both have SPI > devices to insure regressions aren't seen. > > V2 Changes: > Update commit message. > > drivers/spi/spi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c > index 4c638f3..9d5525a 100644 > --- a/drivers/spi/spi.c > +++ b/drivers/spi/spi.c > @@ -2059,11 +2059,11 @@ int spi_setup(struct spi_device *spi) > if (!spi->max_speed_hz) > spi->max_speed_hz = spi->master->max_speed_hz; > > - spi_set_cs(spi, false); > - > if (spi->master->setup) > status = spi->master->setup(spi); > > + spi_set_cs(spi, false); > + > dev_dbg(&spi->dev, "setup mode %d, %s%s%s%s%u bits/w, %u Hz max --> %d\n", > (int) (spi->mode & (SPI_CPOL | SPI_CPHA)), > (spi->mode & SPI_CS_HIGH) ? "cs_high, " : "", > -- > 2.6.1 >
On 10/16/2015 10:45 AM, Andy Shevchenko wrote: > On Fri, Oct 16, 2015 at 6:29 PM, Franklin S Cooper Jr <fcooper@ti.com> wrote: >> SPI controllers may need to be properly setup before chip selects >> can be used. Therefore, wait until the spi controller has a chance >> to perform their setup procedure before trying to use the chip >> select. >> >> This also insures that the chip selects pins are in a good >> state before asseting them which otherwise may cause confusion. >> >> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> > Does it mean I have to test it again? Oops sorry. No the patch hasn't changed. I can shoot a v3 with your tested by included. > >> --- >> Keystone 2 devices currently fail to boot in linux-next after the >> below commit was applied: >> >> spi: bitbang: switch to the generic implementation of transfer_one_message >> commit: 0037686596832572bbca05ab168d9884d7d704c1 >> >> This patch allows Keystone 2 devices to boot again in linux-next. >> >> Tested this patch on K2E evm and am437 starterkit which both have SPI >> devices to insure regressions aren't seen. >> >> V2 Changes: >> Update commit message. >> >> drivers/spi/spi.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c >> index 4c638f3..9d5525a 100644 >> --- a/drivers/spi/spi.c >> +++ b/drivers/spi/spi.c >> @@ -2059,11 +2059,11 @@ int spi_setup(struct spi_device *spi) >> if (!spi->max_speed_hz) >> spi->max_speed_hz = spi->master->max_speed_hz; >> >> - spi_set_cs(spi, false); >> - >> if (spi->master->setup) >> status = spi->master->setup(spi); >> >> + spi_set_cs(spi, false); >> + >> dev_dbg(&spi->dev, "setup mode %d, %s%s%s%s%u bits/w, %u Hz max --> %d\n", >> (int) (spi->mode & (SPI_CPOL | SPI_CPHA)), >> (spi->mode & SPI_CS_HIGH) ? "cs_high, " : "", >> -- >> 2.6.1 >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 16, 2015 at 6:47 PM, Franklin S Cooper Jr. <fcooper@ti.com> wrote: > > > On 10/16/2015 10:45 AM, Andy Shevchenko wrote: >> On Fri, Oct 16, 2015 at 6:29 PM, Franklin S Cooper Jr <fcooper@ti.com> wrote: >>> SPI controllers may need to be properly setup before chip selects >>> can be used. Therefore, wait until the spi controller has a chance >>> to perform their setup procedure before trying to use the chip >>> select. >>> >>> This also insures that the chip selects pins are in a good >>> state before asseting them which otherwise may cause confusion. >>> >>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> >> Does it mean I have to test it again? > Oops sorry. No the patch hasn't changed. I can shoot a v3 with your tested by included. Whatever Mark prefers.
On 10/16/2015 10:55 AM, Andy Shevchenko wrote: > On Fri, Oct 16, 2015 at 6:47 PM, Franklin S Cooper Jr. <fcooper@ti.com> wrote: >> >> On 10/16/2015 10:45 AM, Andy Shevchenko wrote: >>> On Fri, Oct 16, 2015 at 6:29 PM, Franklin S Cooper Jr <fcooper@ti.com> wrote: >>>> SPI controllers may need to be properly setup before chip selects >>>> can be used. Therefore, wait until the spi controller has a chance >>>> to perform their setup procedure before trying to use the chip >>>> select. >>>> >>>> This also insures that the chip selects pins are in a good >>>> state before asseting them which otherwise may cause confusion. >>>> >>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> >>> Does it mean I have to test it again? >> Oops sorry. No the patch hasn't changed. I can shoot a v3 with your tested by included. > Whatever Mark prefers. Hi Mark, I don't see that you pulled this patch into your topic/core branch just yet. Would you prefer for me to shoot a v3 with Andy's tested by or will you just add it when your ready to pull it in? Without this patch several of our boards don't boot in linux-next so if there is anything you need for me to do please let me know. > > -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/27/2015 02:22 PM, Franklin S Cooper Jr. wrote: > > > On 10/16/2015 10:55 AM, Andy Shevchenko wrote: >> On Fri, Oct 16, 2015 at 6:47 PM, Franklin S Cooper Jr. <fcooper@ti.com> wrote: >>> >>> On 10/16/2015 10:45 AM, Andy Shevchenko wrote: >>>> On Fri, Oct 16, 2015 at 6:29 PM, Franklin S Cooper Jr <fcooper@ti.com> wrote: >>>>> SPI controllers may need to be properly setup before chip selects >>>>> can be used. Therefore, wait until the spi controller has a chance >>>>> to perform their setup procedure before trying to use the chip >>>>> select. >>>>> >>>>> This also insures that the chip selects pins are in a good >>>>> state before asseting them which otherwise may cause confusion. >>>>> >>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> >>>> Does it mean I have to test it again? >>> Oops sorry. No the patch hasn't changed. I can shoot a v3 with your tested by included. >> Whatever Mark prefers. > Hi Mark, > I don't see that you pulled this patch into your topic/core branch just yet. Would you prefer > for me to shoot a v3 with Andy's tested by or will you just add it when your ready to > pull it in? > > Without this patch several of our boards don't boot in linux-next so if there is anything you > need for me to do please let me know. >> >> > Boot tested on K2HK: Tested-by: Grygorii Strashko <grygorii.strashko@ti.com> Tested-by: Ivan Khoronzhuk <ivan.khoronzhuk@lonaro.org>
On 10/27/2015 03:11 PM, Grygorii Strashko wrote: > On 10/27/2015 02:22 PM, Franklin S Cooper Jr. wrote: >> >> >> On 10/16/2015 10:55 AM, Andy Shevchenko wrote: >>> On Fri, Oct 16, 2015 at 6:47 PM, Franklin S Cooper Jr. >>> <fcooper@ti.com> wrote: >>>> >>>> On 10/16/2015 10:45 AM, Andy Shevchenko wrote: >>>>> On Fri, Oct 16, 2015 at 6:29 PM, Franklin S Cooper Jr >>>>> <fcooper@ti.com> wrote: >>>>>> SPI controllers may need to be properly setup before chip selects >>>>>> can be used. Therefore, wait until the spi controller has a chance >>>>>> to perform their setup procedure before trying to use the chip >>>>>> select. >>>>>> >>>>>> This also insures that the chip selects pins are in a good >>>>>> state before asseting them which otherwise may cause confusion. >>>>>> >>>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> >>>>> Does it mean I have to test it again? >>>> Oops sorry. No the patch hasn't changed. I can shoot a v3 with your >>>> tested by included. >>> Whatever Mark prefers. >> Hi Mark, >> I don't see that you pulled this patch into your topic/core branch >> just yet. Would you prefer >> for me to shoot a v3 with Andy's tested by or will you just add it >> when your ready to >> pull it in? >> >> Without this patch several of our boards don't boot in linux-next so >> if there is anything you >> need for me to do please let me know. >>> >>> >> > > Boot tested on K2HK: > > Tested-by: Grygorii Strashko <grygorii.strashko@ti.com> > Tested-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> > Sry, Fix Ivan's e-mail Tested-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
On Tue, Oct 27, 2015 at 07:22:51AM -0500, Franklin S Cooper Jr. wrote: > I don't see that you pulled this patch into your topic/core branch just yet. Would you prefer > for me to shoot a v3 with Andy's tested by or will you just add it when your ready to > pull it in? Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. Please don't send content free pings. If your patch has been lost then you will need to resend it, if your patch is waiting to be handled then at best your message is likely to be threaded in with the original thread and therefore not seen. Either way a content free ping just adds to mail volume rather than helping.
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 4c638f3..9d5525a 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -2059,11 +2059,11 @@ int spi_setup(struct spi_device *spi) if (!spi->max_speed_hz) spi->max_speed_hz = spi->master->max_speed_hz; - spi_set_cs(spi, false); - if (spi->master->setup) status = spi->master->setup(spi); + spi_set_cs(spi, false); + dev_dbg(&spi->dev, "setup mode %d, %s%s%s%s%u bits/w, %u Hz max --> %d\n", (int) (spi->mode & (SPI_CPOL | SPI_CPHA)), (spi->mode & SPI_CS_HIGH) ? "cs_high, " : "",
SPI controllers may need to be properly setup before chip selects can be used. Therefore, wait until the spi controller has a chance to perform their setup procedure before trying to use the chip select. This also insures that the chip selects pins are in a good state before asseting them which otherwise may cause confusion. Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> --- Keystone 2 devices currently fail to boot in linux-next after the below commit was applied: spi: bitbang: switch to the generic implementation of transfer_one_message commit: 0037686596832572bbca05ab168d9884d7d704c1 This patch allows Keystone 2 devices to boot again in linux-next. Tested this patch on K2E evm and am437 starterkit which both have SPI devices to insure regressions aren't seen. V2 Changes: Update commit message. drivers/spi/spi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)