what about mach-shark?

what about mach-shark?

[Nicolas Pitre]

Is this used?

While it probably does compile, it is likely to oops soon after boot. I 
notice that it defines UNCACHEABLE_ADDR to 0xdf010000 in 
mach-shark/include/mach/hardware.h which is used by cpu_sa110_do_idle in 
mm/proc-sa110.S, and therefore it must be a virtual address.  However I 
can't find where this 0xdf010000 is actually mapped.

So either no one has been using this for a long time as this is not 
going to run past a schedule to the idle loop, or I'm missing something 
obvious.  If the former I'm proposing to remove mach-shark from the 
tree, if the later I'd like to know where the actual mapping for that 
0xdf010000 is.


Nicolas

what about mach-shark?

[Russell King - ARM Linux]

On Mon, Jul 04, 2011 at 04:08:56PM -0400, Nicolas Pitre wrote:
> 
> Is this used?
> 
> While it probably does compile, it is likely to oops soon after boot. I 
> notice that it defines UNCACHEABLE_ADDR to 0xdf010000 in 
> mach-shark/include/mach/hardware.h which is used by cpu_sa110_do_idle in 
> mm/proc-sa110.S, and therefore it must be a virtual address.  However I 
> can't find where this 0xdf010000 is actually mapped.
> 
> So either no one has been using this for a long time as this is not 
> going to run past a schedule to the idle loop, or I'm missing something 
> obvious.  If the former I'm proposing to remove mach-shark from the 
> tree, if the later I'd like to know where the actual mapping for that 
> 0xdf010000 is.

You're missing something.

FYI:

arch/arm/mach-shark/include/mach/memory.h:#define FLUSH_BASE           0xdf000000

arch/arm/mm/mmu.c:
        /*
         * Map the cache flushing regions.
         */
#ifdef FLUSH_BASE
        map.pfn = __phys_to_pfn(FLUSH_BASE_PHYS);
        map.virtual = FLUSH_BASE;
        map.length = SZ_1M;
        map.type = MT_CACHECLEAN;
        create_mapping(&map);
#endif
#ifdef FLUSH_BASE_MINICACHE
        map.pfn = __phys_to_pfn(FLUSH_BASE_PHYS + SZ_1M);
        map.virtual = FLUSH_BASE_MINICACHE;
        map.length = SZ_1M;
        map.type = MT_MINICLEAN;
        create_mapping(&map);
#endif

And 64K < 1M, so its covered by the cache flush mapping.  Exactly the
same applies to RiscPC which worked last time I tried it.

what about mach-shark?

[Nicolas Pitre]

On Mon, 4 Jul 2011, Russell King - ARM Linux wrote:

> You're missing something.
> 
> FYI:
> 
> arch/arm/mach-shark/include/mach/memory.h:#define FLUSH_BASE           0xdf000000
> 
> arch/arm/mm/mmu.c:
>         /*
>          * Map the cache flushing regions.
>          */
> #ifdef FLUSH_BASE
>         map.pfn = __phys_to_pfn(FLUSH_BASE_PHYS);
>         map.virtual = FLUSH_BASE;
>         map.length = SZ_1M;
>         map.type = MT_CACHECLEAN;
>         create_mapping(&map);
> #endif
> #ifdef FLUSH_BASE_MINICACHE
>         map.pfn = __phys_to_pfn(FLUSH_BASE_PHYS + SZ_1M);
>         map.virtual = FLUSH_BASE_MINICACHE;
>         map.length = SZ_1M;
>         map.type = MT_MINICLEAN;
>         create_mapping(&map);
> #endif
> 
> And 64K < 1M, so its covered by the cache flush mapping.  Exactly the
> same applies to RiscPC which worked last time I tried it.

OK.  In that case, UNCACHEABLE_ADDR is not truly "uncacheable", which 
might inhibit clock switching in cpu_sa110_do_idle, no?


Nicolas

what about mach-shark?

[Russell King - ARM Linux]

On Mon, Jul 04, 2011 at 06:20:25PM -0400, Nicolas Pitre wrote:
> OK.  In that case, UNCACHEABLE_ADDR is not truly "uncacheable", which 
> might inhibit clock switching in cpu_sa110_do_idle, no?

Possibly, and this may be a bug which was never noticed - the same
aflicts RiscPC too which has no ill effects noticed.  That's been
well hammered over the years with that code as it stands.

It's probably less risky to leave it be rather than trying to fix it.

what about mach-shark?

[Nicolas Pitre]

On Mon, 4 Jul 2011, Russell King - ARM Linux wrote:

> On Mon, Jul 04, 2011 at 06:20:25PM -0400, Nicolas Pitre wrote:
> > OK.  In that case, UNCACHEABLE_ADDR is not truly "uncacheable", which 
> > might inhibit clock switching in cpu_sa110_do_idle, no?
> 
> Possibly, and this may be a bug which was never noticed - the same
> aflicts RiscPC too which has no ill effects noticed.  That's been
> well hammered over the years with that code as it stands.

The only effect might be less than optimal power consumption when idle.  
But I guess that RiscPC and Shark are not battery powered machines 
and therefore no one cared much.

> It's probably less risky to leave it be rather than trying to fix it.

Problem is that this is getting in the way of some cleanups I'm doing.  
So this is going to be fixed as a side effect of one of my patches.  
Hopefully someone with the hardware will be able to test it.


Nicolas

what about mach-shark?

[Linus Walleij]

On Mon, Jul 4, 2011 at 10:08 PM, Nicolas Pitre <nico@fluxnic.net> wrote:

> Is this used?

This still goes unanswered after two years.

Alexander, are you compiling and booting recent kernels on the Shark?

I recently had a dream to convert some platforms and eventually
all of the arch/arm machines to GENERIC_CLOCKEVENTS and
some other things, but that require that arch maintainers can
review and test patches, and if they can't, why keep it around,
so

PING

Yours,
Linus Walleij

what about mach-shark?

[Russell King - ARM Linux]

On Mon, Aug 26, 2013 at 09:04:05PM +0200, Linus Walleij wrote:
> On Mon, Jul 4, 2011 at 10:08 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> 
> > Is this used?
> 
> This still goes unanswered after two years.
> 
> Alexander, are you compiling and booting recent kernels on the Shark?
> 
> I recently had a dream to convert some platforms and eventually
> all of the arch/arm machines to GENERIC_CLOCKEVENTS and

You're not going to achieve that pipedream.  Really.  There are platforms
still around which don't have enough timers to be able to do anything but
periodic interrupts at a fixed rate - with nothing available as a clock
source other than the kernel jiffy counter incremented by that periodic
interrupt (which would create a circular dependency.)

Remember: with periodic interrupts, the clock source is read at every
interrupt to discover how many jiffies have passed since the previous
interrupt - which is useless if you have just a single reloading timer.

what about mach-shark?

[Linus Walleij]

On Mon, Aug 26, 2013 at 9:06 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Aug 26, 2013 at 09:04:05PM +0200, Linus Walleij wrote:
>> On Mon, Jul 4, 2011 at 10:08 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>>
>> > Is this used?
>>
>> This still goes unanswered after two years.
>>
>> Alexander, are you compiling and booting recent kernels on the Shark?
>>
>> I recently had a dream to convert some platforms and eventually
>> all of the arch/arm machines to GENERIC_CLOCKEVENTS and
>
> You're not going to achieve that pipedream.  Really.  There are platforms
> still around which don't have enough timers to be able to do anything but
> periodic interrupts at a fixed rate - with nothing available as a clock
> source other than the kernel jiffy counter incremented by that periodic
> interrupt (which would create a circular dependency.)

Yes, I guess I will run into them... But I guess it doesn't hurt to
convert over the remaining machines that can actually do this
the right way.

Yours,
Linus Walleij

what about mach-shark?

[Alexander Schulz]

Linus Walleij writes:

> On Mon, Jul 4, 2011 at 10:08 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>
>> Is this used?
>
> This still goes unanswered after two years.
>
> Alexander, are you compiling and booting recent kernels on the Shark?
>

Sorry, it must have slipped through somehow, I would have answered it if I  
had seen it. I still have an eye on the list but haven't found the time to  
really do anything with the shark in the recent time.

Best regards
   Alexander

what about mach-shark?

[Linus Walleij]

On Wed, Aug 28, 2013 at 11:05 AM, Alexander Schulz <alex@shark-linux.de> wrote:
>> On Mon, Jul 4, 2011 at 10:08 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>>
>>> Is this used?
>>
>> This still goes unanswered after two years.
>>
>> Alexander, are you compiling and booting recent kernels on the Shark?
>
> Sorry, it must have slipped through somehow, I would have answered it if I
> had seen it. I still have an eye on the list but haven't found the time to
> really do anything with the shark in the recent time.

Does this mean you will find that soon-ish, or can we delete the
machine?

Deletion is not definitive, it can be reverted by git revert if you find
time to pick it up further down the road, we're mainly trying to
avoid generic maintenance on machines that may not even
boot.

Yours,
Linus Walleij

what about mach-shark?

[Alexander Schulz]

Hello,

I don't like it beeing deleted, but I do understand your concerns and if I  
am honest to myself I will have to admit that I probably won't find the  
time at least for this year.

Regards
   Alexander



Linus Walleij writes:

> On Wed, Aug 28, 2013 at 11:05 AM, Alexander Schulz <alex@shark-linux.de> wrote:
>>> On Mon, Jul 4, 2011 at 10:08 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>>>
>>>> Is this used?
>>>
>>> This still goes unanswered after two years.
>>>
>>> Alexander, are you compiling and booting recent kernels on the Shark?
>>
>> Sorry, it must have slipped through somehow, I would have answered it if I
>> had seen it. I still have an eye on the list but haven't found the time to
>> really do anything with the shark in the recent time.
>
> Does this mean you will find that soon-ish, or can we delete the
> machine?
>
> Deletion is not definitive, it can be reverted by git revert if you find
> time to pick it up further down the road, we're mainly trying to
> avoid generic maintenance on machines that may not even
> boot.
>
> Yours,
> Linus Walleij