[U-Boot] dm: Should U-Boot driver model abandon platform data?

[U-Boot] dm: Should U-Boot driver model abandon platform data?

[Simon Glass]

Hi,

This question came up at the U-Boot mini-summit yesterday and I was
tasked with starting a thread on the mailing list.

There seemed to be a strong feeling in the room that permitting
platform data in driver model is a mistake. Reasons mentioned were:

- device tree is how things are done in Linux at least for most
platforms we support
- we can therefore import this directly in from Linux rather than
writing new platform data
- platform data is considered 'legacy' and we should not support
legacy features in a new framework
- device tree permits fully abstracting the device data from the code,
avoiding #ifdefs
- it is easier to change settings in device tree than in platform data

The main impact is that all boards would need at least some sort of
device tree when they move to driver model.

There is also the question of SPL, where we are sometimes
space-constrained. If we go with this policy I wonder if we should
permit an exception for things required by SPL for now? Typically in
SPL for these space-constrained platforms we only need a few devices
so we could provide platform data for SPL while still using device
tree in U-Boot  It would be possible to enable device tree in SPL for
many platforms but that feels like something that should not block
progress. So perhaps platform data in SPL should be a separate
question.

Please have a think about this and reply on this thread.

Regards,
Simon

[U-Boot] dm: Should U-Boot driver model abandon platform data?

[Jagan Teki]

On 14 October 2014 10:20, Simon Glass <sjg@chromium.org> wrote:
> Hi,
>
> This question came up at the U-Boot mini-summit yesterday and I was
> tasked with starting a thread on the mailing list.
>
> There seemed to be a strong feeling in the room that permitting
> platform data in driver model is a mistake. Reasons mentioned were:
>
> - device tree is how things are done in Linux at least for most
> platforms we support
> - we can therefore import this directly in from Linux rather than
> writing new platform data
> - platform data is considered 'legacy' and we should not support
> legacy features in a new framework
> - device tree permits fully abstracting the device data from the code,
> avoiding #ifdefs
> - it is easier to change settings in device tree than in platform data
>
> The main impact is that all boards would need at least some sort of
> device tree when they move to driver model.

I'm not fully agree with the statement "platform data should not be part of
driver model".

Yes this statement is fine when we code platform data with fully functional
devicetree driven u-boot ie possible in Linux now. I think going forward,
this platform data will be part of devicetree based on u-boot devicetree
development on all possible area's till that platform data is not a legacy
for u-boot.

Comments?

>
> There is also the question of SPL, where we are sometimes
> space-constrained. If we go with this policy I wonder if we should
> permit an exception for things required by SPL for now? Typically in
> SPL for these space-constrained platforms we only need a few devices
> so we could provide platform data for SPL while still using device
> tree in U-Boot  It would be possible to enable device tree in SPL for
> many platforms but that feels like something that should not block
> progress. So perhaps platform data in SPL should be a separate
> question.
>
> Please have a think about this and reply on this thread.

thanks!
-- 
Jagan.

[U-Boot] dm: Should U-Boot driver model abandon platform data?

[Masahiro YAMADA]

Hi Simon,


2014-10-14 13:50 GMT+09:00 Simon Glass <sjg@chromium.org>:
> Hi,
>
> This question came up at the U-Boot mini-summit yesterday and I was
> tasked with starting a thread on the mailing list.
>
> There seemed to be a strong feeling in the room that permitting
> platform data in driver model is a mistake. Reasons mentioned were:
>
> - device tree is how things are done in Linux at least for most
> platforms we support
> - we can therefore import this directly in from Linux rather than
> writing new platform data
> - platform data is considered 'legacy' and we should not support
> legacy features in a new framework
> - device tree permits fully abstracting the device data from the code,
> avoiding #ifdefs
> - it is easier to change settings in device tree than in platform data
>
> The main impact is that all boards would need at least some sort of
> device tree when they move to driver model.
>
> There is also the question of SPL, where we are sometimes
> space-constrained. If we go with this policy I wonder if we should
> permit an exception for things required by SPL for now? Typically in
> SPL for these space-constrained platforms we only need a few devices
> so we could provide platform data for SPL while still using device
> tree in U-Boot  It would be possible to enable device tree in SPL for
> many platforms but that feels like something that should not block
> progress. So perhaps platform data in SPL should be a separate
> question.
>
> Please have a think about this and reply on this thread.


Well, I believe we should allow to use platform data
on Normal as well as SPL.

Device Tree is costly in terms of the binary size
(it needs to build lib/libfdt and some other files),
so we should keep it optional.

I see no benefits of using device tree on U-boot
for architectures that do not support it in Linux.


-- 
Best Regards
Masahiro Yamada

[U-Boot] dm: Should U-Boot driver model abandon platform data?

[Igor Grinberg]

Hi,

On 10/14/14 07:50, Simon Glass wrote:
> Hi,
> 
> This question came up at the U-Boot mini-summit yesterday and I was
> tasked with starting a thread on the mailing list.
> 
> There seemed to be a strong feeling in the room that permitting
> platform data in driver model is a mistake. Reasons mentioned were:
> 
> - device tree is how things are done in Linux at least for most
> platforms we support

What about non-DT architectures?
Also, what about boards that do not intend to use Linux?
Should we force them to also use DT?

> - we can therefore import this directly in from Linux rather than
> writing new platform data

What about corner cases where some driver gets added for U-Boot,
but does not exist in Linux and that will have bindings problem
as those could be problematic from Linux DT stable ABI POV.

> - platform data is considered 'legacy' and we should not support
> legacy features in a new framework
> - device tree permits fully abstracting the device data from the code,
> avoiding #ifdefs

Yet there are cases where board specific code should run
before/during/after driver initialization and that is something DT
cannot provide.

> - it is easier to change settings in device tree than in platform data

That statement, I actually, do not completely agree with.

> 
> The main impact is that all boards would need at least some sort of
> device tree when they move to driver model.
> 
> There is also the question of SPL, where we are sometimes
> space-constrained. If we go with this policy I wonder if we should
> permit an exception for things required by SPL for now? Typically in
> SPL for these space-constrained platforms we only need a few devices
> so we could provide platform data for SPL while still using device
> tree in U-Boot  It would be possible to enable device tree in SPL for
> many platforms but that feels like something that should not block
> progress. So perhaps platform data in SPL should be a separate
> question.

Once we have platform data in SPL, means that drivers should
support both, so I don't really see any reason why not also support
platform data in regular build.

I think that it would be wise to keep the flexibility and let the
driver/board maintainer to decide what would be a better choice.
Also, since things are not that straight forward today, may be we
can support both ways and see how things are (not)working out?
and have the same discussion after we have worked/supported/maintained
this (or is it a bad choice?).

-- 
Regards,
Igor.