On 8/23/2013 10:47 PM, Santosh Shilimkar wrote: > On Friday 23 August 2013 01:08 PM, Sekhar Nori wrote: >> On 8/13/2013 7:01 PM, Santosh Shilimkar wrote: >>> On Tuesday 13 August 2013 07:19 AM, Will Deacon wrote: >>>> On Mon, Aug 12, 2013 at 07:34:13PM +0100, Santosh Shilimkar wrote: >>>>> On Friday 02 August 2013 11:48 AM, Will Deacon wrote: >>>>>> I think this an A9-specific register, which reads as 0 on UP A9 and reads as >>>>>> some form of PERIPH_BASE for SMP parts. The issue I have is when PERIPH_BASE >>>>>> is zero. >>>>>> >>>>> What do we do here ? Should we document this in the code and proceed ? >>>>> Mostly there is no platform with PERIPH_BASE = 0, so its should be fine but >>>>> I am open for any other alternative. >>>> >>>> The only other alternative I can think of is forcing people to have >>>> CONFIG_SMP=n, but that blows away single zImage for your platform. >>>> >>> Yep which surely we don't want considering after so much effort we >>> have it working first place. How about going ahead with assumption >>> that PERIPH_BASE = 0 case doesn't work. >> >> I must be missing something but why cannot we use the SCU configuration >> register "CPU number" field to determine that its a UP? I do not have an >> OMAP4 board, but on AM437x, it certainly indicates only CPU0 present. >> > Thats what patch does. Yes, you are missing the point of dicussion. Right, I see that now after actually reading the complete patch :) > On real UP Cortex-A9, the base address read will return '0' which is > treated as invalid address in the patch. Will D pointed out that one Is this something defined by spec for all UP Cortex-A9 or just an observation on AM437x implementation? It sounds like the later? Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
