Following up on this:
2011/1/24 Russell King - ARM Linux :
> On Mon, Jan 24, 2011 at 12:27:16PM -, Pawel Moll wrote:
>> So - we'll try to enlarge FIFO. For the moment - playing with interrupts
>> affinity seem to be a viable workaround.
>
> I don't think enlarging the FIFO will help too much.
> So, I do hope that someone decides to implement something more reasonable
> if Versatile Express were to get a DMA controller. If it's another PL08x
> then it isn't worth it - it won't work.
More likely it will be DMA-330 formerly known as PL330. But as I said -
it's about the chip that Core Ti
> Have you considered switching the ISP1761 handler to
> request_threaded_irq() with IRQF_ONESHOT | IRQF_NO_SUSPEND
> so it runs in process context with that IRQ masked off, until completion?
That's something that Will suggested, but no - I didn't try it. This may
be worth discussing with the ISP1
On Tue, Feb 01, 2011 at 01:34:59PM +, Pawel Moll wrote:
> > And to prove the point, I have MMCI running at up to 4Mbps, an 8 fold
> > increase over what the current fixed upper-rate implementation does.
> > The adaptive rate implementation is just a proof of concept at the
> > moment and requir
2011/1/21 Russell King - ARM Linux :
> On Fri, Jan 21, 2011 at 05:20:57PM -0500, Nicolas Pitre wrote:
>> The only solution in that case is to give top priority to the FIFO IRQ
>> and never disable IRQs when in interrupt context, except for that FIFO
>> servicing handler which should keep IRQs maske
> And to prove the point, I have MMCI running at up to 4Mbps, an 8 fold
> increase over what the current fixed upper-rate implementation does.
> The adaptive rate implementation is just a proof of concept at the
> moment and requires further work to improve the rate selection algorithm.
Great, I'v
On Mon, Jan 24, 2011 at 11:10:50PM +, Russell King - ARM Linux wrote:
> I guess you haven't thought about moving MMCI to an adaptive clocking
> solution? What I'm suggesting is halve the clock rate on FIFO error
> and retry. Increase the clock rate on each successful transfer up
> to the maxi
On Mon, Jan 24, 2011 at 07:59:03PM +, Pawel Moll wrote:
> > If you're flooding the system with USB traffic, enlargening the
> > FIFO size won't help. Making the FIFO larger just decreases the
> > _interrupt_ _latency_ requirements. It doesn't mean you can
> > cope with the amount of data bein
> If you're flooding the system with USB traffic, enlargening the
> FIFO size won't help. Making the FIFO larger just decreases the
> _interrupt_ _latency_ requirements. It doesn't mean you can
> cope with the amount of data being transferred.
On VE both ISP and MMCI are sharing the same static
On Mon, Jan 24, 2011 at 05:54:18PM -, Pawel Moll wrote:
> $ git am 0001-arm-Improve-MMC-performance-on-Versatile-Express.patch
>
> / # uname -a
> Linux (none) 2.6.38-rc2+ #12 SMP Mon Jan 24 17:41:53 GMT 2011 armv7l GNU/Linux
> / # cat /dev/sda > /dev/null &
> / # dd if=/dev/mmcblk0 of=/dev/nul
> My final mail on this subject.
Ah, and I was really enjoying our pleasant discussion...
> Take a mainline kernel. Apply the attached three patches. MMC
> will then work without any problems. No hacks required. There is
> *absolutely* *no* need to waste time with hardware modifications.
>
>
My final mail on this subject. I'm adding Philippe and Catalin so that
they're in the loop on this.
Take a mainline kernel. Apply the attached three patches. MMC will then
work without any problems. No hacks required. There is *absolutely* *no*
need to waste time with hardware modifications.
On Mon, Jan 24, 2011 at 04:39:21PM -, Pawel Moll wrote:
> > Well, fixing MMCI because ISP1761 is buggy is not the way forward.
> > The answer is to fix the broken ISP1761 driver.
>
> Totally agree. The thing is that you are the only person right now who
> doesn't have any problems.
That's not
> Given that the problem is already fixed via a set of patches, I see
> no reason to mess about with the hardware, thereby making the driver
> more complicated for *no* benefit.
There will be virtually no change in the driver - all required stuff is already
there. See the STE UX500 variant - they
On Mon, Jan 24, 2011 at 04:24:00PM +, Russell King - ARM Linux wrote:
> On Mon, Jan 24, 2011 at 04:13:14PM +, Pawel Moll wrote:
> > > The real answer is to avoid PIO mode, and use DMA support.
> > > However,
> > > I've had problems using DMA on the ARM development boards. You can
> >
> >
On Mon, Jan 24, 2011 at 04:13:14PM +, Pawel Moll wrote:
> > I don't think enlarging the FIFO will help too much. The issue is
> > whether the CPU can keep up with the data rate coming off the card.
> > If it can't, then no matter how large the FIFO is, it will
> > eventually overflow.
>
> Yes
> I don't think enlarging the FIFO will help too much. The issue is
> whether the CPU can keep up with the data rate coming off the card.
> If it can't, then no matter how large the FIFO is, it will
> eventually overflow.
Yes, I realize that. But so far the only time when problem happens is the
On Mon, Jan 24, 2011 at 12:27:16PM -, Pawel Moll wrote:
> So - we'll try to enlarge FIFO. For the moment - playing with interrupts
> affinity seem to be a viable workaround.
I don't think enlarging the FIFO will help too much. The issue is
whether the CPU can keep up with the data rate coming
> Wouldn't the ultimate solution be to simply use FIQs to service the
> MMC FIFO?
The ultimate solution is to super-size FIFO ;-) It's not impossible (as the
motherboard peripherals live in a FPGA), but according to our board people may
be tricky due to the MMCI design (it's just ancient, that'
On Fri, Jan 21, 2011 at 05:20:57PM -0500, Nicolas Pitre wrote:
> The only solution in that case is to give top priority to the FIFO IRQ
> and never disable IRQs when in interrupt context, except for that FIFO
> servicing handler which should keep IRQs masked out throughout. In any
> case this w
On Fri, 21 Jan 2011, Russell King - ARM Linux wrote:
> On Fri, Jan 21, 2011 at 02:59:35PM -0500, Nicolas Pitre wrote:
> > On Fri, 21 Jan 2011, Pawel Moll wrote:
> >
> > > VE suffers from serious problem with MMC transfers - low performance,
> > > errors when other IO peripherals (especially USB)
On Fri, Jan 21, 2011 at 02:59:35PM -0500, Nicolas Pitre wrote:
> On Fri, 21 Jan 2011, Pawel Moll wrote:
>
> > VE suffers from serious problem with MMC transfers - low performance,
> > errors when other IO peripherals (especially USB) are used at the
> > same time etc.
> >
> > It all boils down to
On Fri, 21 Jan 2011, Pawel Moll wrote:
> VE suffers from serious problem with MMC transfers - low performance,
> errors when other IO peripherals (especially USB) are used at the
> same time etc.
>
> It all boils down to the MMC controller short FIFO and - in result -
> timing constrains. The mos
A word of comment...
At least some of the Linaro file system images are running irqbalance
daemon, which will most likely play with MMC and USB interrupts
affiliation in runtime. To prevent it from doing so,
/etc/default/irqbalance should contain this line:
export IRQBALANCE_BANNED_INTERRUPT
Hello.
Pawel Moll wrote:
VE suffers from serious problem with MMC transfers - low performance,
errors when other IO peripherals (especially USB) are used at the
same time etc.
It all boils down to the MMC controller short FIFO and - in result -
timing constrains. The most problematic case -
25 matches
Mail list logo
