Re: OMAP totally fucked?

["Cousson, Benoit" <b-cousson@ti.com>]

On 3/3/2012 10:21 PM, Tony Lindgren wrote:
> * Russell King - ARM Linux<linux@arm.linux.org.uk>  [120303 12:20]:
>> On Sat, Mar 03, 2012 at 12:34:48PM -0800, Tony Lindgren wrote:
>>> * Tony Lindgren<tony@atomide.com>  [120303 11:56]:
>>>> * Tony Lindgren<tony@atomide.com>  [120303 11:29]:
>>>>> * Russell King - ARM Linux<linux@arm.linux.org.uk>  [120303 10:57]:
>>>>>>
>>>>>> Even with the full config, making oldconfig I get:
>>>>>>
>>>>>> OMAP2420 support (SOC_OMAP2420) [Y/n] (NEW)
>>>>>> OMAP2430 support (SOC_OMAP2430) [Y/n] (NEW)
>>>>>> OMAP3430 support (SOC_OMAP3430) [Y/n] (NEW)
>>>>>> TI81XX support (SOC_OMAPTI81XX) [Y/n] (NEW)
>>>>>> AM33XX support (SOC_OMAPAM33XX) [Y/n] (NEW)
>>>>>> OMAP44XX support (SOC_OMAP44XX) [Y/n] (NEW)
>>>>>>
>>>>>> May I remind you of this mail from Linus:
>>>>>>
>>>>>> 	https://lkml.org/lkml/2012/1/6/354
>>>>>>
>>>>>> So really this is a rather horrid mess.
>>>>>
>>>>> Hmm yes. Sounds like we need to remove the defaults and instead
>>>>> add them to omap2plus_defconfig.
>>>>>
>>>>> I'll do a patch to fix that.
>>>>
>>>> How about the following patch after we revert commit 72b026a4?
>>>>
>>>> That still leaves the randconfig not necessarily selecting
>>>> any of ARCH_OMAP2/3/4 issue, but that can be dealt separately
>>>> later on.
>>>
>>> Grr, need to look at it more.. Now it leaves out ARCH_OMAP2/3/4
>>> when doing a make oldconfig with some existing .config file.
>>
>> There's also something else wrong:
>>
>> *
>> * OMAP Core Type
>> *
>> OMAP2420 support (SOC_OMAP2420) [Y/n] (NEW) n
>> OMAP2430 support (SOC_OMAP2430) [Y/n] (NEW) n
>> OMAP3430 support (SOC_OMAP3430) [Y/n] (NEW) n
>> TI81XX support (SOC_OMAPTI81XX) [Y/n] (NEW) n
>> AM33XX support (SOC_OMAPAM33XX) [Y/n] (NEW) n
>> OMAP44XX support (SOC_OMAP44XX) [Y/n] (NEW) n
>> *
>> * OMAP Board Type
>> *
>> Generic OMAP2+ board (MACH_OMAP_GENERIC) [Y/?] y
>> OMAP3 debugging peripherals (OMAP3_EMU) [N/y/?] (NEW)
>> Enable SDRC AC timing register changes (OMAP3_SDRC_AC_TIMING) [N/y/?] (NEW)
>>
>> Shouldn't the last two options depend on OMAP3 stuff?
>
> Yes it should. Looks like the default n there can go too.
>
> I think the best solution is to have the board select the
> omap type. From user point of view there's really no need
> to have separate menu for selecting the omap type, selecting
> just the board is a bit more intuitive.
>
> Anyways, we should revert commit 72b026a4 because of the
> breakage it causes.
>
>> And why do we have:
>>
>> config ARCH_OMAP2PLUS
>> 	select USE_OF
>>
>> Do we really _need_ OF, or is it just irqdomain that's required?
>
> Let's check, maybe the irqdomain is still enough here except
> for MACH_OMAP_GENERIC to here. Eventually we'll be needing OF,
> but that's still few merge cycles away.

We added that to avoid cluttering the drivers with a bunch of #ifdef 
CONFIG_OF as proposed by Grant and Rob... and most drivers adaptation 
were done having that assumption.
So if we removed that today, it will be like removing the IRQDOMAIN 
define during the last merge window, it will break when the drivers DT 
adaptation will be pulled.

Regards,
Benoit