On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@xxxxxx> [130404 04:15]:
>> + Tero and few more TI folks,
>>
>> On Thursday 04 April 2013 01:12 AM, Paul Walmsley wrote:
>>> Hi Santosh
>>>
>>> On Wed, 3 Apr 2013, Santosh Shilimkar wrote:
>>>
>>>> Thes patchset has already missed last couple of merge windows and its the
>>>> biggest bottleneck in getting OMAP5 booting from mainline. So I request
>>>> you to please have a look it quickly so that Tony can line that up for
>>>> 3.10.
>>>
>>> Looks like there are a few minor issues with the patches based on a quick
>>> look. I'll post those to the list shortly; they should be easy to fix.
>>> But those issues aren't my real concern with this series.
>>>
>>> What's harder to fix are the underlying process issues. My main concern
>>> is that these patches add almost 9,000 lines of code and data. We've
>>> received clear guidance from the upstream ARM SoC maintainers that any
>>> significant new additions need to be balanced with moving a similar number
>>> of lines of code and data out of arch/arm/{plat-,mach-}* into drivers/.
>>> (Or the new patches should be accompanied with patches that show obvious
>>> progress towards the goal of moving code and data out of
>>> arch/arm/{plat-,mach-}*.) We need to see more help from TI on the
>>> prerequisites for this cleanup process.
>>>
>> I agree that we are not making faster progress but as part of the
>> $subject series itself, for DT only build, we removed around ~4000
>> lines of data from hwmod. After the merge window, we can trim
>> the AM33XX and then later OMAP4 when it is made DT only support.
>> That should give us another 6000 lines of negative diff.
>> At the same time removal of MUX data for OMAP4 should be
>> around 2000 lines of negative diff.
>
> Can't we already trim the am33xx hwmod data after your patches for
> v3.10 as am33xx is already DT only? Unfortunately we cannot create
> negative diffstat in other ways for v3.10 merge window as we cannot
> make omap4 DT only just quite yet.
>
Yes we can and I can take a stab it tomorrow. The only thing is I
might need some support for testing but thats manageable. Will
take a stab at it tomorrow and if everything goes well, post a
patch for smae.
> FYI, I have some trivial patches here to drop board and mux support for
> omap4 once we can make omap4 DT only, so that will be about 3000 lines
> of reduction with estimated 1000 - 2000 lines once I go through the
> unneeded platform init code for omap4 for things like MMC and USB.
>
Cool.
> The rest of the clean-up issues I believe we all agree, we just need
> to get it done so we can avoid getting flamed for every new SoC for
> the huge data files. To fix the data issue for good, it seems that we can
> get started moving both the clock and hwmod data to simple drivers
> that can get clocks and hwmod data both from DT and /lib/firmware.
> It also seems that we don't need to move all the data at once, which
> makes the task easier.
>
Agree.
regards,
santosh
--
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
