> On Wed, Nov 15, 2017 at 01:51:54PM +0100, Marc Gonzalez wrote:
> > On 01/11/2017 20:38, Marc Gonzalez wrote:
> >
> > > OK, I'll just send my patch, and then crawl back under my rock.
> >
> > Linus,
> >
> > As promised, the patch is provided below. And as promised, I will
> > no longer bring th
Hi!
> On Wed, Nov 1, 2017 at 2:26 AM, Russell King - ARM Linux
> wrote:
> > On Tue, Oct 31, 2017 at 05:23:19PM -0700, Doug Anderson wrote:
> >> Hi,
> >>
> >> On Tue, Oct 31, 2017 at 10:45 AM, Linus Torvalds
> >> wrote:
> >> > So I'm very much open to udelay improvements, and if somebody sends
>
On Mon, Nov 20, 2017 at 09:38:46AM -0800, Doug Anderson wrote:
> Hi,
>
> On Thu, Nov 16, 2017 at 3:22 PM, Russell King - ARM Linux
> wrote:
> > On Thu, Nov 16, 2017 at 02:15:02PM -0800, Doug Anderson wrote:
> >> Hi,
> >>
> >> On Thu, Nov 16, 2017 at 1:05 PM, Marc Gonzalez
> >> wrote:
> >> > On 1
Hi,
On Thu, Nov 16, 2017 at 3:22 PM, Russell King - ARM Linux
wrote:
> On Thu, Nov 16, 2017 at 02:15:02PM -0800, Doug Anderson wrote:
>> Hi,
>>
>> On Thu, Nov 16, 2017 at 1:05 PM, Marc Gonzalez
>> wrote:
>> > On 16/11/2017 18:05, Russell King - ARM Linux wrote:
>> >
>> >> On Thu, Nov 16, 2017 at
On Thu, Nov 16, 2017 at 02:15:02PM -0800, Doug Anderson wrote:
> Hi,
>
> On Thu, Nov 16, 2017 at 1:05 PM, Marc Gonzalez
> wrote:
> > On 16/11/2017 18:05, Russell King - ARM Linux wrote:
> >
> >> On Thu, Nov 16, 2017 at 05:42:36PM +0100, Marc Gonzalez wrote:
> >>
> >>> Requesting 100 µs and spinni
Hi,
On Thu, Nov 16, 2017 at 1:05 PM, Marc Gonzalez
wrote:
> On 16/11/2017 18:05, Russell King - ARM Linux wrote:
>
>> On Thu, Nov 16, 2017 at 05:42:36PM +0100, Marc Gonzalez wrote:
>>
>>> Requesting 100 µs and spinning only 25 µs is still a problem,
>>> don't you agree?
>>
>> Which is why, as I'v
On 16/11/2017 18:05, Russell King - ARM Linux wrote:
> On Thu, Nov 16, 2017 at 05:42:36PM +0100, Marc Gonzalez wrote:
>
>> Requesting 100 µs and spinning only 25 µs is still a problem,
>> don't you agree?
>
> Which is why, as I've said *many* times already, that drivers are written
> with leaway
On Thu, Nov 16, 2017 at 05:42:36PM +0100, Marc Gonzalez wrote:
> On 16/11/2017 17:32, Russell King - ARM Linux wrote:
> > On Thu, Nov 16, 2017 at 05:26:32PM +0100, Marc Gonzalez wrote:
> >> On 16/11/2017 17:08, Nicolas Pitre wrote:
> >>
> >>> On Thu, 16 Nov 2017, Marc Gonzalez wrote:
> >>>
> O
On Thu, 16 Nov 2017, Marc Gonzalez wrote:
> On 16/11/2017 17:47, Nicolas Pitre wrote:
>
> > Look at cpufreq_callback() in arch/arm/kernel/smp.c.
>
> Are you pointing at the scaling of loops_per_jiffy done in that function?
>
> As I wrote earlier:
>
> If I'm reading arch/arm/kernel/smp.c correc
On 16/11/2017 17:47, Nicolas Pitre wrote:
> Look at cpufreq_callback() in arch/arm/kernel/smp.c.
Are you pointing at the scaling of loops_per_jiffy done in that function?
As I wrote earlier:
If I'm reading arch/arm/kernel/smp.c correctly, loops_per_jiffy is scaled
when the frequency changes.
B
On Thu, 16 Nov 2017, Marc Gonzalez wrote:
> On 16/11/2017 17:08, Nicolas Pitre wrote:
>
> > On Thu, 16 Nov 2017, Marc Gonzalez wrote:
> >
> >> On 16/11/2017 16:36, Russell King - ARM Linux wrote:
> >>> On Thu, Nov 16, 2017 at 04:26:51PM +0100, Marc Gonzalez wrote:
> On 15/11/2017 14:13, Rus
On 16/11/2017 17:32, Russell King - ARM Linux wrote:
> On Thu, Nov 16, 2017 at 05:26:32PM +0100, Marc Gonzalez wrote:
>> On 16/11/2017 17:08, Nicolas Pitre wrote:
>>
>>> On Thu, 16 Nov 2017, Marc Gonzalez wrote:
>>>
On 16/11/2017 16:36, Russell King - ARM Linux wrote:
> On Thu, Nov 16, 201
On Thu, Nov 16, 2017 at 05:26:32PM +0100, Marc Gonzalez wrote:
> On 16/11/2017 17:08, Nicolas Pitre wrote:
>
> > On Thu, 16 Nov 2017, Marc Gonzalez wrote:
> >
> >> On 16/11/2017 16:36, Russell King - ARM Linux wrote:
> >>> On Thu, Nov 16, 2017 at 04:26:51PM +0100, Marc Gonzalez wrote:
> On 1
On 16/11/2017 17:08, Nicolas Pitre wrote:
> On Thu, 16 Nov 2017, Marc Gonzalez wrote:
>
>> On 16/11/2017 16:36, Russell King - ARM Linux wrote:
>>> On Thu, Nov 16, 2017 at 04:26:51PM +0100, Marc Gonzalez wrote:
On 15/11/2017 14:13, Russell King - ARM Linux wrote:
> udelay() needs to
On Thu, 16 Nov 2017, Marc Gonzalez wrote:
> On 16/11/2017 16:36, Russell King - ARM Linux wrote:
> > On Thu, Nov 16, 2017 at 04:26:51PM +0100, Marc Gonzalez wrote:
> >> On 15/11/2017 14:13, Russell King - ARM Linux wrote:
> >>
> >>> udelay() needs to offer a consistent interface so that drivers kn
On 16/11/2017 16:36, Russell King - ARM Linux wrote:
> On Thu, Nov 16, 2017 at 04:26:51PM +0100, Marc Gonzalez wrote:
>> On 15/11/2017 14:13, Russell King - ARM Linux wrote:
>>
>>> udelay() needs to offer a consistent interface so that drivers know
>>> what to expect no matter what the implementati
On Thu, Nov 16, 2017 at 04:26:51PM +0100, Marc Gonzalez wrote:
> On 15/11/2017 14:13, Russell King - ARM Linux wrote:
>
> > udelay() needs to offer a consistent interface so that drivers know
> > what to expect no matter what the implementation is. Making one
> > implementation conform to your id
On 15/11/2017 14:13, Russell King - ARM Linux wrote:
> udelay() needs to offer a consistent interface so that drivers know
> what to expect no matter what the implementation is. Making one
> implementation conform to your ideas while leaving the other
> implementations with other expectations is
Hi,
On Wed, Nov 15, 2017 at 4:51 AM, Marc Gonzalez
wrote:
> On 01/11/2017 20:38, Marc Gonzalez wrote:
>
>> OK, I'll just send my patch, and then crawl back under my rock.
>
> Linus,
>
> As promised, the patch is provided below. And as promised, I will
> no longer bring this up on LKML.
>
> FWIW,
On Wed, Nov 15, 2017 at 01:51:54PM +0100, Marc Gonzalez wrote:
> On 01/11/2017 20:38, Marc Gonzalez wrote:
>
> > OK, I'll just send my patch, and then crawl back under my rock.
>
> Linus,
>
> As promised, the patch is provided below. And as promised, I will
> no longer bring this up on LKML.
>
On 01/11/2017 20:38, Marc Gonzalez wrote:
> OK, I'll just send my patch, and then crawl back under my rock.
Linus,
As promised, the patch is provided below. And as promised, I will
no longer bring this up on LKML.
FWIW, I have checked that the computed value matches the expected
value for all H
On Wed, 1 Nov 2017 21:48:22 +0200
Baruch Siach wrote:
> Hi Marc,
>
> On Wed, Nov 01, 2017 at 08:03:20PM +0100, Marc Gonzalez wrote:
> > On 01/11/2017 18:53, Alan Cox wrote:
> > > For that matter given the bad blocks don't randomly change why not cache
> > > them ?
> >
> > That's a good que
On Wed, Nov 01, 2017 at 08:28:18PM +0100, Marc Gonzalez wrote:
> On 01/11/2017 10:26, Russell King - ARM Linux wrote:
>
> > On Tue, Oct 31, 2017 at 05:23:19PM -0700, Doug Anderson wrote:
> >
> >> On Tue, Oct 31, 2017 at 10:45 AM, Linus Torvalds wrote:
> >>
> >>> So I'm very much open to udelay imp
Hi Marc,
On Wed, Nov 01, 2017 at 08:03:20PM +0100, Marc Gonzalez wrote:
> On 01/11/2017 18:53, Alan Cox wrote:
> > For that matter given the bad blocks don't randomly change why not cache
> > them ?
>
> That's a good question, I'll ask the NAND framework maintainer.
> Store them where, by the wa
On Wed, 1 Nov 2017, Marc Gonzalez wrote:
> On 01/11/2017 18:53, Alan Cox wrote:
>
> > On Tue, 31 Oct 2017 17:15:34 +0100
> >
> >> Therefore, users are accustomed to having delays be longer (within a
> >> reasonable margin).
> >> However, very few users would expect delays to be *shorter* than re
On 01/11/2017 20:09, Linus Torvalds wrote:
> On Wed, Nov 1, 2017 at 12:03 PM, Marc Gonzalez wrote:
>
>> By default, ndelay is implemented in terms of udelay.
>
> That's very much *NOT* the case.
>
> Yes, there is a *fallback* for when somebody doesn't do ndelay() at
> all, but that doesn't make
> > serialized link. Writes get delayed, they can bunch together, busses do
> > posting and queueing.
>
> Are you talking about the actual delay operation, or the pokes around it?
All of it. A write from the CPU except on the lowest end ones isn't
neccessarily going to occur in strict sequentia
On 01/11/2017 10:26, Russell King - ARM Linux wrote:
> On Tue, Oct 31, 2017 at 05:23:19PM -0700, Doug Anderson wrote:
>
>> On Tue, Oct 31, 2017 at 10:45 AM, Linus Torvalds wrote:
>>
>>> So I'm very much open to udelay improvements, and if somebody sends
>>> patches for particular platforms to do p
On Wed, Nov 1, 2017 at 12:09 PM, Linus Torvalds
wrote:
>
> Yes, there is a *fallback* for when somebody doesn't do ndelay() at
> all, but that doesn't make it the default.
>
> It's just a "the architecture didn't implement ndelay at all, we'll
> work around it".
Side note: I will continue to cla
On Wed, Nov 1, 2017 at 12:03 PM, Marc Gonzalez
wrote:
>
> By default, ndelay is implemented in terms of udelay.
That's very much *NOT* the case.
Yes, there is a *fallback* for when somebody doesn't do ndelay() at
all, but that doesn't make it the default.
It's just a "the architecture didn't im
On 01/11/2017 18:53, Alan Cox wrote:
> On Tue, 31 Oct 2017 17:15:34 +0100
>
>> Therefore, users are accustomed to having delays be longer (within a
>> reasonable margin).
>> However, very few users would expect delays to be *shorter* than requested.
>
> If your udelay can be under by 10% then ju
On Tue, 31 Oct 2017 17:15:34 +0100
> Therefore, users are accustomed to having delays be longer (within a
> reasonable margin).
> However, very few users would expect delays to be *shorter* than requested.
If your udelay can be under by 10% then just bump the number by 10%.
However at that level
Hi,
On Wed, Nov 1, 2017 at 2:26 AM, Russell King - ARM Linux
wrote:
> On Tue, Oct 31, 2017 at 05:23:19PM -0700, Doug Anderson wrote:
>> Hi,
>>
>> On Tue, Oct 31, 2017 at 10:45 AM, Linus Torvalds
>> wrote:
>> > So I'm very much open to udelay improvements, and if somebody sends
>> > patches for p
On Tue, Oct 31, 2017 at 05:23:19PM -0700, Doug Anderson wrote:
> Hi,
>
> On Tue, Oct 31, 2017 at 10:45 AM, Linus Torvalds
> wrote:
> > So I'm very much open to udelay improvements, and if somebody sends
> > patches for particular platforms to do particularly well on that
> > platform, I think we
Hi,
On Tue, Oct 31, 2017 at 10:45 AM, Linus Torvalds
wrote:
> So I'm very much open to udelay improvements, and if somebody sends
> patches for particular platforms to do particularly well on that
> platform, I think we should merge them. But ...
If I'm reading this all correctly, this sounds li
On Tue, Oct 31, 2017 at 10:45 AM, Linus Torvalds
wrote:
>
> So I'm very much open to udelay improvements, and if somebody sends
> patches for particular platforms to do particularly well on that
> platform, I think we should merge them. But ...
Side note: this is obviously a negative feedback cir
On Tue, Oct 31, 2017 at 9:56 AM, Russell King - ARM Linux
wrote:
>
> Marc is stating something that's incorrect there. On ARM32, we don't
> have a TSC, and we aren't guaranteed to have a timer usable for delays.
> Where there is a suitable timer, it can be used for delays.
>
> However, where ther
On Tue, Oct 31, 2017 at 09:44:20AM -0700, Linus Torvalds wrote:
> On Tue, Oct 31, 2017 at 9:15 AM, Marc Gonzalez
> wrote:
> >
> > On arm32, it is possible to set up udelay() to be clock-based.
>
> I'm not sure why this is discussed as some kind of generic problem.
Hi Linus,
Marc is stating some
On Tue, Oct 31, 2017 at 05:15:34PM +0100, Marc Gonzalez wrote:
> I am writing to you directly because Russell has bluntly stated (paraphrased)
> "Send your patches to Linus; it's his kernel, and he has the final say." which
> is his diplomatic way of telling me to fsck off.
... after I've already
On Tue, Oct 31, 2017 at 9:15 AM, Marc Gonzalez
wrote:
>
> On arm32, it is possible to set up udelay() to be clock-based.
I'm not sure why this is discussed as some kind of generic problem.
Just do what x86-64 already does. We use the TSC, and ndelay() does
the right thing too.
I've not checked
Hello BDFL,
I am writing to you directly because Russell has bluntly stated (paraphrased)
"Send your patches to Linus; it's his kernel, and he has the final say." which
is his diplomatic way of telling me to fsck off.
Basically, I want to improve the accuracy of clock-based delays, in order to
im
41 matches
Mail list logo
