Hi Nicolas,
Am 09.04.21 um 12:54 schrieb Nicolas Saenz Julienne:
> Hi again,
>
> On Wed, 2021-04-07 at 16:37 -0400, Alan Cooper wrote:
>> Nicolas,
>>
>> I got a better description of the failure and it looks like the bus
>> clock needs to be limited to 300KHz for a 500MHz core clock.
>> What's
Hi again,
On Wed, 2021-04-07 at 16:37 -0400, Alan Cooper wrote:
> Nicolas,
>
> I got a better description of the failure and it looks like the bus
> clock needs to be limited to 300KHz for a 500MHz core clock.
> What's happening is that an internal reset sequence is needed after a
> command
Hi Al,
On Wed, 2021-04-07 at 16:37 -0400, Alan Cooper wrote:
> Nicolas,
>
> I got a better description of the failure and it looks like the bus
> clock needs to be limited to 300KHz for a 500MHz core clock.
> What's happening is that an internal reset sequence is needed after a
> command timeout
Nicolas,
I got a better description of the failure and it looks like the bus
clock needs to be limited to 300KHz for a 500MHz core clock.
What's happening is that an internal reset sequence is needed after a
command timeout and the reset signal needs to be asserted for at least
2 ticks of the bus
Hi Alan,
On Thu, 2021-04-01 at 11:23 -0400, Alan Cooper wrote:
> Nicolas,
>
> Sorry, I just noticed this thread.
> This is a known bug in some newer Arasan cores.
> The problem happens when the difference between the core clock and the bus
> clock is too great.
> Limiting the clock to 200KHz
Nicolas,
Sorry, I just noticed this thread.
This is a known bug in some newer Arasan cores.
The problem happens when the difference between the core clock and the
bus clock is too great.
Limiting the clock to 200KHz minimum should be a good fix.
In my experience, it's only eMMC that needs the
Am 26.03.21 um 17:17 schrieb Nicolas Saenz Julienne:
> On Thu, 2021-03-25 at 20:11 +0100, Stefan Wahren wrote:
>> Am 24.03.21 um 16:34 schrieb Nicolas Saenz Julienne:
>>> Hi Stefan,
>>>
>>> On Wed, 2021-03-24 at 16:16 +0100, Stefan Wahren wrote:
Hi Nicolas,
Am 22.03.21 um 19:58
On Thu, 2021-03-25 at 20:11 +0100, Stefan Wahren wrote:
> Am 24.03.21 um 16:34 schrieb Nicolas Saenz Julienne:
> > Hi Stefan,
> >
> > On Wed, 2021-03-24 at 16:16 +0100, Stefan Wahren wrote:
> > > Hi Nicolas,
> > >
> > > Am 22.03.21 um 19:58 schrieb Nicolas Saenz Julienne:
> > > > From: Nicolas
Am 24.03.21 um 16:34 schrieb Nicolas Saenz Julienne:
> Hi Stefan,
>
> On Wed, 2021-03-24 at 16:16 +0100, Stefan Wahren wrote:
>> Hi Nicolas,
>>
>> Am 22.03.21 um 19:58 schrieb Nicolas Saenz Julienne:
>>> From: Nicolas Saenz Julienne
>>>
>>> Force emmc2's frequency to 150MHz as the default 100MHz
Hi Stefan,
On Wed, 2021-03-24 at 16:16 +0100, Stefan Wahren wrote:
> Hi Nicolas,
>
> Am 22.03.21 um 19:58 schrieb Nicolas Saenz Julienne:
> > From: Nicolas Saenz Julienne
> >
> > Force emmc2's frequency to 150MHz as the default 100MHz (set by FW)
> > seems to interfere with the VPU clock when
Hi Nicolas,
Am 22.03.21 um 19:58 schrieb Nicolas Saenz Julienne:
> From: Nicolas Saenz Julienne
>
> Force emmc2's frequency to 150MHz as the default 100MHz (set by FW)
> seems to interfere with the VPU clock when setup at frequencies bigger
> than 500MHz (a pretty common case). This ends up
On Mon, 2021-03-22 at 12:06 -0700, Scott Branden wrote:
> 1st line of commit should be ARM: dts: bcm2711
Ouch, of course... Sorry for that.
Regards,
Nicolas
signature.asc
Description: This is a digitally signed message part
1st line of commit should be ARM: dts: bcm2711
On 2021-03-22 11:58 a.m., Nicolas Saenz Julienne wrote:
> From: Nicolas Saenz Julienne
>
> Force emmc2's frequency to 150MHz as the default 100MHz (set by FW)
> seems to interfere with the VPU clock when setup at frequencies bigger
> than 500MHz (a
From: Nicolas Saenz Julienne
Force emmc2's frequency to 150MHz as the default 100MHz (set by FW)
seems to interfere with the VPU clock when setup at frequencies bigger
than 500MHz (a pretty common case). This ends up causing unwarranted
SDHCI CMD hangs when no SD card is present.
14 matches
Mail list logo
