Re: [PATCH 2/2] I2C: Implement DMA support into mxs-i2c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > >  static int mxs_i2c_finish_read(struct mxs_i2c_dev *i2c, u8 *buf, int
> > >  len) {
> > > 
> > > -	u32 data;
> > > +	u32 data = 0;
> > 
> > Unrelated, useless change.
> 
> Have you tried compiling the code with gcc 4.7?

What has the compiler version to do with the relevance? :) This has
nothing to do with adding DMA support. Plus, nobody so far could tell me
what path gcc is seeing there.

> > > +	i2c->dma_mode = 1;
> > 
> > Have you measured the overhead of DMA? I'd still think that
> > 
> > 	if (MX23 || msg->len > 24)
> > 		do_dma
> > 	else
> > 		do_pioqueue
> > 
> > might be worth considered.
> 
> It might, but in the 2.6.35.3 I have from FSL, it only does:
> 
> WARN_ONCE(len > 24, "choose DMA mode if xfer len > 24 bytes\n");

Well, we are back to the "FSL code is just a reference" topic. I truly
hope that part was implemented because of laziness and not because of
hardware limitations.

> Also, I tried switching PIOQUEUE/DMA, but didn't get it working. We might as 
> well make this dma/pioqueue mode configurable as well as speed via platform data 
> until someone comes up with a patch that can mix pioqueue and dma?

User configuration is not an option here IMO, because PIOQUEUE would still
fail for bigger transfers. "Always DMA" might be better then. But I will
try to switch modes this week, that's just too tempting.

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux