Wow, at last some reaction. And I thought nobody cares ...
BTW, removing CONFIG_MMC_CLKGATE helped a bit, because the pointless
clock-off-clock-on while the device is booting (or accessing multiple
sectors within a short time) isn't going to happen anymore.
But really, a mdelay(1) in a driver
On Wed, Jul 08, 2015 at 08:22:57AM +0200, Holger Schurig wrote:
Wow, at last some reaction. And I thought nobody cares ...
BTW, removing CONFIG_MMC_CLKGATE helped a bit, because the pointless
clock-off-clock-on while the device is booting (or accessing multiple
sectors within a short time)
Hi Holger,
Adding some more folks on Cc.
On Tue, Jun 30, 2015 at 10:43 AM, Holger Schurig
holgerschu...@gmail.com wrote:
Hi,
I noticed in a kernel 4.0.7 that I loose CAN packets when an incoming
rsync transfer changes my eMMC or SD-Card image. I used CONFIG_FRACE
to find why this is the
On Tue, Jul 07, 2015 at 03:17:08PM -0300, Fabio Estevam wrote:
On Tue, Jun 30, 2015 at 10:43 AM, Holger Schurig
holgerschu...@gmail.com wrote:
So it seems that esdhc_pltfm_set_clock() somehow waits. And really
there is an mdelay(1) there. So it waits a whopping millisecond there!
What's
Hi,
I noticed in a kernel 4.0.7 that I loose CAN packets when an incoming
rsync transfer changes my eMMC or SD-Card image. I used CONFIG_FRACE
to find why this is the case, and came to this trace:
# tracer: preemptoff
#
# preemptoff latency trace v1.1.5 on 4.0.7
#
