From: Nikita Kiryanov <nikita@compulab.co.il>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/3] spi: omap3: add support for more word lengths
Date: Tue, 15 Oct 2013 14:09:45 +0300 [thread overview]
Message-ID: <525D2279.3060807@compulab.co.il> (raw)
In-Reply-To: <525BFD38.5020800@compulab.co.il>
On 10/14/2013 05:18 PM, Igor Grinberg wrote:
>> diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
>> index 6bac245..add98e1 100644
>> --- a/drivers/spi/omap3_spi.c
>> +++ b/drivers/spi/omap3_spi.c
>> @@ -20,7 +20,7 @@
>> #include <asm/io.h>
>> #include "omap3_spi.h"
>>
>> -#define WORD_LEN 8
>> +#define SPI_DEFAULT_WORDLEN 8;
>
> As already pointed out, the semicolon should not be there...
Will fix
>
>> #define SPI_WAIT_TIMEOUT 3000000;
>
> While at this, can you please, send a separate patch
> to fix the above semicolon?
Will do
>
>>
>> static void spi_reset(struct omap3_spi_slave *ds)
>> @@ -128,10 +128,32 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
>> ds->regs = regs;
>> ds->freq = max_hz;
>> ds->mode = mode;
>> + ds->wordlen = SPI_DEFAULT_WORDLEN;
>
> While we know, OMAP SPI controller supports this,
> I think many other controllers can also support this feature
> and thus their drivers can benefit from this option.
>
> Wouldn't it be better to add the wordlen field to the generic slave
> structure instead of the OMAP specific structure?
Makes sense. Will move wordlen to struct spi_slave.
>
>>
>> return &ds->slave;
>> }
>>
>> +int spi_set_wordlen(struct spi_slave *slave, unsigned int wordlen)
>> +{
>> + struct omap3_spi_slave *ds;
>> + int chconf;
>> +
>> + if (wordlen < 4 || wordlen > 32) {
>> + printf("SPI error: unsupported wordlen %d\n", wordlen);
>> + return -1;
>> + }
>> +
>> + ds = to_omap3_spi(slave);
>> + ds->wordlen = wordlen;
>> +
>> + chconf = readl(&ds->regs->channel[ds->slave.cs].chconf);
>> + chconf &= ~OMAP3_MCSPI_CHCONF_WL_MASK;
>> + chconf |= (wordlen - 1) << 7;
>> + omap3_spi_write_chconf(ds, chconf);
>
> I would recommend to update the controller just before the transaction
> takes place, e.g. in spi_xfer() function, so the spi_set_wordlen() function
> will only update the slave structure and will not touch the hardware.
> Thus spi_set_wordlen() can be placed in the generic SPI code.
Yes that is better. Will do.
>>
>> -int omap3_spi_write(struct spi_slave *slave, unsigned int len, const u8 *txp,
>> +int omap3_spi_write(struct spi_slave *slave, unsigned int len, const void *txp,
>> unsigned long flags)
>> {
>> struct omap3_spi_slave *ds = to_omap3_spi(slave);
>> @@ -250,7 +272,13 @@ int omap3_spi_write(struct spi_slave *slave, unsigned int len, const u8 *txp,
>> }
>> }
>> /* Write the data */
>> - writel(txp[i], &ds->regs->channel[ds->slave.cs].tx);
>> + unsigned int *tx = &ds->regs->channel[ds->slave.cs].tx;
>> + if (ds->wordlen > 16)
>> + writel(((u32 *)txp)[i], tx);
>> + else if (ds->wordlen > 8)
>> + writel(((u16 *)txp)[i], tx);
>> + else
>> + writel(((u8 *)txp)[i], tx);
>
> Can we always have u32 for the txp and use masks ans shifts instead of
> the ugly castings?
Working with masks and shifts will basically do the same thing that the
casts do, but in a more complicated way. The best way to get rid of the
casts will be to store SPI words in u32 arrays to begin with,
regardless of the size of SPI word. Unfortunately, this is actually a
difficult change:
If we change omap3_spi implementation to work with u32 arrays we also
have to change cmd_spi.c, which stores data in byte arrays, and then
we will be forced to change all the other U-Boot SPI implementations.
Due to the scope of this change I think it should be done in another
patch series.
--
Regards,
Nikita.
next prev parent reply other threads:[~2013-10-15 11:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-09 14:46 [U-Boot] [PATCH 0/3] Add support for SPI based DataImage LCD panel Nikita Kiryanov
2013-10-09 14:46 ` [U-Boot] [PATCH 1/3] spi: omap3: add support for more word lengths Nikita Kiryanov
2013-10-10 15:26 ` Gerhard Sittig
2013-10-14 14:18 ` Igor Grinberg
2013-10-15 11:09 ` Nikita Kiryanov [this message]
2013-10-09 14:46 ` [U-Boot] [PATCH 2/3] lcd: add DataImage SCF0403x LCD panel support Nikita Kiryanov
2013-10-10 16:57 ` Anatolij Gustschin
2013-10-14 14:34 ` Igor Grinberg
2013-10-09 14:46 ` [U-Boot] [PATCH 3/3] cm_t35: use scf0403 driver Nikita Kiryanov
2013-10-10 17:01 ` Anatolij Gustschin
2013-10-15 6:38 ` Igor Grinberg
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=525D2279.3060807@compulab.co.il \
--to=nikita@compulab.co.il \
--cc=u-boot@lists.denx.de \
/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