Re: [PATCH] spi: spi-rspi: add dmaengine supporting
On Thu, Apr 19, 2012 at 07:22:53PM +0900, Shimoda, Yoshihiro wrote:
+static struct dma_async_tx_descriptor *rspi_dma_prep_sg(struct scatterlist
*sg,
+ void *buf, unsigned len, struct dma_chan *chan,
+ enum dma_transfer_direction dir)
+{
+ sg_init_table(sg, 1);
+ sg_set_buf(sg, buf, len);
+ sg_dma_len(sg) = len,
+ dma_map_sg(chan-device-dev, sg, 1, dir);
+ return dmaengine_prep_slave_sg(chan, sg, 1, dir,
+DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+}
+
..
+ desc = rspi_dma_prep_sg(sg, buf, len, rspi-chan_tx, DMA_TO_DEVICE);
+ if (!desc) {
+ ret = -EIO;
+ goto error;
+ }
+
..
+error:
+ if (rspi-dma_width_16bit)
+ kfree(buf);
+
+ return ret;
+}
+
The sg list handling is unbalanced. Specifically you always map the
scatterlist with dma_map_sg() but you have no corresponding
dma_unmap_sg() anywhere, either in the error path or your regular exit
path.
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: spi-sh: add IORESOURCE_MEM_TYPE_MASK decoding for access size
On Thu, Jan 26, 2012 at 05:43:57PM +0900, Shimoda, Yoshihiro wrote:
This SPI controller's access size is 32, or 8-bit. The previous driver
supported 32-bit only. So, this patch adds IORESOURCE_MEM_TYPE_MASK
decoding, an then, the driver can handle the SPI controller of 8-bit.
This patch also changes the readl/writel to ioread*/iowrite*.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
drivers/spi/spi-sh.c | 25 +++--
1 files changed, 23 insertions(+), 2 deletions(-)
..
static void spi_sh_set_bit(struct spi_sh_data *ss, unsigned long val,
@@ -464,6 +473,18 @@ static int __devinit spi_sh_probe(struct platform_device
*pdev)
ss = spi_master_get_devdata(master);
dev_set_drvdata(pdev-dev, ss);
+ switch (res-flags IORESOURCE_MEM_TYPE_MASK) {
+ case IORESOURCE_MEM_8BIT:
+ ss-width = 8;
+ break;
+ case IORESOURCE_MEM_32BIT:
+ ss-width = 32;
+ break;
+ default:
+ dev_err(pdev-dev, No support width\n);
+ ret = -ENODEV;
+ goto error1;
If the default up to this point has been 32-bit only then it makes sense
for 32 to still remain the default. The 8-bit user is presumably a new
one and therefore has no existing platform data configuration to worry
about, while this change would require existing users to be updated for
the new 32-bit flag to behave the same way they have up until now.
If you wish to do this incrementally then you can of course convert all
of the existing platforms to the new mechanism for 32-bit as well and
then simply error out as above for the undefined width case, but I still
think it makes more sense to have a usable default.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: spi-sh: add IORESOURCE_MEM_TYPE_MASK decoding for access size
On Fri, Jan 27, 2012 at 10:14:49AM +0900, Shimoda, Yoshihiro wrote:
2012/01/26 19:22, Paul Mundt wrote:
On Thu, Jan 26, 2012 at 05:43:57PM +0900, Shimoda, Yoshihiro wrote:
[ snip ]
static void spi_sh_set_bit(struct spi_sh_data *ss, unsigned long val,
@@ -464,6 +473,18 @@ static int __devinit spi_sh_probe(struct
platform_device *pdev)
ss = spi_master_get_devdata(master);
dev_set_drvdata(pdev-dev, ss);
+ switch (res-flags IORESOURCE_MEM_TYPE_MASK) {
+ case IORESOURCE_MEM_8BIT:
+ ss-width = 8;
+ break;
+ case IORESOURCE_MEM_32BIT:
+ ss-width = 32;
+ break;
+ default:
+ dev_err(pdev-dev, No support width\n);
+ ret = -ENODEV;
+ goto error1;
If the default up to this point has been 32-bit only then it makes sense
for 32 to still remain the default. The 8-bit user is presumably a new
one and therefore has no existing platform data configuration to worry
about, while this change would require existing users to be updated for
the new 32-bit flag to behave the same way they have up until now.
Thank you for your comment.
Unfortunately, the value of IORESOURCE_MEM_8BIT is (03), so existing users
will not enter to the default.
Ah, ok, I missed that. In that case I suppose your original patch makes
the most sense. We should be able to roll in the platform update patch
early anyways.
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/3] SPI: spi_sh_msiof: cosmetic clean-up
On Mon, Jan 24, 2011 at 10:26:55PM -0700, Grant Likely wrote: On Mon, Jan 24, 2011 at 10:02 PM, Simon Horman ho...@verge.net.au wrote: Surely this is a bug in diff. Or perhaps put more politely, diff isn't smart enough to realise a) this is C and b) xxx: isn't a valid function name in C. Oh, perhaps. But regardless, it is long-standing behaviour and the single space convention is widely used. Nobody seems offended enough by it to go and change diff. To see, just do: git grep '^ [a-zA-Z0-9_]*:' If it were particularly ugly, or actively dangerous, then I'd be against this pattern, but it is neither and it noticeably improves diff readability. It's largely a personal preference thing. I personally don't care for the leading spaces, and remove them whenever I encounter them. I know that Magnus and some others like to use them however, so generally don't care one way or the other. I assume general apathy has a lot to do with diff not being fixed (note that this topic does come up from time to time, where the general conclusion is that someone should probably do something about it, at some point in time). -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 3/3] SPI: spi_sh_msiof: fix wrong address calculation, which leads to an Oops
On Fri, Jan 21, 2011 at 09:27:43AM -0700, Grant Likely wrote: On Fri, Jan 21, 2011 at 04:56:47PM +0100, Guennadi Liakhovetski wrote: NULL + small offset != NULL, but reading from that small offset address is usually not a very good idea and often leads to problems, like kernel Oopses in this case, easily reproducible by writing to an SD-card, used in SPI mode. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Applied, thanks. Since this is an oops fix, I'll push this one to Linus before the next -rc. The other two can go into linux-next for 2.6.39. I haven't been following too closely, but this may also be a good -stable candidate. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [GIT PULL] sh updates for 2.6.33-rc7
On Tue, Feb 02, 2010 at 01:17:49AM -0700, Grant Likely wrote: On Mon, Feb 1, 2010 at 9:06 PM, Paul Mundt let...@linux-sh.org wrote: Please pull from: ? ? ? ?master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git sh/for-2.6.33 Which contains: Magnus Damm (1): ? ? ?usb: r8a66597-hdc disable interrupts fix Marek Skuczynski (2): ? ? ?sh: Fix access to released memory in dwarf_unwinder_cleanup() ? ? ?sh: Fix access to released memory in clk_debugfs_register_one() Markus Pietrek (1): ? ? ?spi: spi_sh_msiof: Fixed data sampling on the correct edge Hold the phone; please coordinate with me before picking up SPI patches into your tree. I don't mind arch specific spi changes going in via a different tree, but I'd like to know about it before I waste time farting around with the same patch (like I did with this one tonight, and only found out that you also picked it up when I came across this pull request by chance). If there's someone actively looking after the SPI stuff then that's fine. I didn't bother bouncing this one off of the SPI list since it's a hardware-specific correctness fix and has no dependency on anything subsystem related. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH] spi: SuperH MSIOF SPI Master driver
On Wed, Nov 25, 2009 at 12:11:52PM -0800, Andrew Morton wrote:
On Tue, 24 Nov 2009 21:55:31 +0900
Magnus Damm magnus.d...@gmail.com wrote:
+struct sh_msiof_spi_priv {
+ struct spi_bitbang bitbang; /* must be first for spi_bitbang.c */
Well if that's the case then spi_bitbang.c needs smacking. What causes
this requirement?
spi_bitbang causes this requirement by being lazy with regards to
private data stashing. Both the drivers and the bitbang code use
spi_master_get_devdata() for getting their private data, which wraps
in to a dev_get_drvdata().
This needs to be reworked so that struct spi_master has its own private
data pointer which helper code like spi_bitbang can use, while freeing up
the struct device private data pointer so it can be freely used by
drivers as normal.
This is the same sort of private data through casting whimsy that the
framebuffer drivers used to employ, only fortunately that behaviour never
made it out of 2.3.x kernels -- until now!
+ void __iomem *mapbase;
+ struct clk *clk;
+ struct platform_device *pdev;
+ struct sh_msiof_spi_info *info;
+ struct completion done;
+ unsigned long flags;
+ int tx_fifo_size;
+ int rx_fifo_size;
+};
+
...
+static void sh_msiof_modify_ctr_wait(struct sh_msiof_spi_priv *p,
+unsigned long clr, unsigned long set)
+{
+ unsigned long mask = clr | set;
+ unsigned long data;
+
+ data = sh_msiof_read(p, CTR);
+ data = ~clr;
+ data |= set;
+ sh_msiof_write(p, CTR, data);
+
+ while ((sh_msiof_read(p, CTR) mask) != set)
+ ;
hm, confidence. No timeout needed here?
This definitely needs a timeout, nothing involving SPI inspires
confidence. A cpu_relax() to prevent the compiler from optimizing the
loop out would help, too.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [RFT PATCH] SuperH HSPI controller driver.
On Mon, Jul 21, 2008 at 11:07:44AM +0200, Manuel Lauss wrote: Here is a very simple driver for the HSPI block on many SuperH processors. I could only subject it to limited testings, as my sole SPI device here is a write-only 8bit digital poti. It seems to do the right thing as far as I could see on an oscilloscope. The driver doesn't do DMA and pushes/pops bytes one-at-a-time from/to fifos (I'm going to fix that at a later time). Please test and comment! Thanks, Manuel Lauss --- A simple driver for the HSPI block found on many SuperH processors. Signed-off-by: Manuel Lauss [EMAIL PROTECTED] I have no outstanding issues with this, though I did just break it with the header reorg. If David is fine with it and wants to Ack it, I can take it through my tree. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [RFT PATCH] SuperH HSPI controller driver.
On Mon, Jul 21, 2008 at 11:07:44AM +0200, Manuel Lauss wrote:
+out2:
+ release_resource(priv-ioarea);
+ kfree(priv-ioarea);
What is this kfree() for?
+static int __devexit hspi_remove(struct platform_device *pdev)
+{
+ struct hspi_priv *priv = platform_get_drvdata(pdev);
+
+ spi_bitbang_stop(priv-bitbang);
+ iowrite32(0, priv-io + SPCR);
+ iowrite32(0, priv-io + SPSCR);
+ iowrite32(0, priv-io + SPSR);
+ free_irq(priv-irq, priv);
+ iounmap(priv-io);
+ release_resource(priv-ioarea);
+ kfree(priv-ioarea);
Likewise here.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
