Re: [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/2/2011 12:48 PM, Tony Lindgren wrote:
* Cousson, Benoit<b-cousson@xxxxxx>  [110902 11:26]:
On 9/2/2011 10:12 AM, Tony Lindgren wrote:
* Benoit Cousson<b-cousson@xxxxxx>   [110901 19:52]:
In order to avoid conflict with the new board-omap3-dt.c file,
remove the .dt_compat entry from the beagle regular board
file.

Any DT work for OMAP3 will have to be done on the generic DT
board file to avoid breaking the legacy board support until
DT migration is done.

In general we should not keep duplicate old non-DT data around
now that we have the DT append support. Instead we should just
require the .dts file appended to zImage for all mach-omap2
machines. Otherwise we'll end up with double bloat :)

Mmm, I'm not sure to get your point. We are not duplicating, since a
pure DT generic board will not have anything except a
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
And the regular board files will keep initializing devices statically.
The drivers will then for the moment support both pdata and DT
method to get board parameters.

Well when converting a driver to DT, we should just drop pdata
support. No need to keep it around as it will just make it harder
for us to clean up afterwards.

I'm not sure it is that simple. We have 20+ OMAP3+ boards supported so far. Dropping pdata when a driver is adapted means that all these boards should be properly adapted to DT and tested... (board-XXX.dts + board-XXX.c). That's a huge effort for my point of view. Whereas keeping the legacy pdata method will allow progressing on the boart-dt only without breaking any legacy boards. It will allow the board manufacturers to potentially do the DTS file for their own system using then the generic board-dt.c file.

That being said, keeping the legacy pdata code in some driver along with the DT is a big pain as well:-( In some cases, DT can even provide some good way to encode HW information that we do not have today with hwmod/omap_device. So in that case we do not even have any alternative method yet.

So it's OK to have the DT entries in board files so drivers
that get converted will work with them.

Well, it will be a little bit more tricky, because having DT in
current board files will be a mess with a bunch of #ifdef CONFIG_OF,
and adding DT compatible inside each boards will prevent the pure
generic DT one to work. In that case we will duplicate the DT
migration in every legacy boards files...

We should just select CONFIG_OF deal with it that way.

That's why the current strategy is to keep the current board files
non-DT aware and add the DT support only to the generic DT board
file.

Well I don't like that, it will be a big mess. We'll end up with
twice the amount of platform_data and init code. It's OK to
require CONFIG_OF as it's known to work with the append support
for older boards.

It's easier just to require DT append for all the boards. In most
cases it's just a trivial include of the common dts file for now.

That part is easy indeed, this is hacking every board-XXX.c and testing them that will be tricky. This is as well the board specifics settings that are tricky not the generic OMAP stuff. We do have to set GPIOs, pin mux, regulator bindings, audio codec stuff...

When we convert something to DT, there's no point going back.

Agree on that, in theory, I'm just wondering how practical it will be to progress on every board at the same time.

I guess we do need some advice from the DT gurus on that as well.

It looks to me that both approaches are painful and will require some efforts. It is too bad that nobody did a devicetree-migration-o-matic-for-lazy-developer.py script to handle that...

Regards,
Benoit

--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux