[GIT PULL] fbdev fixes for 3.19

Hi Linus,

Please pull fbdev changes for 3.19.

 Tomi

The following changes since commit 0df1f2487d2f0d04703f142813d53615d62a1da4:

  Linux 3.18-rc3 (2014-11-02 15:01:51 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-3.19

for you to fetch changes up to 3315764efceaccfb02c7d4c99ef8eed6716cd861:

  Merge branches '3.19/omapdss' and '3.19/simplefb' into fbdev (2014-12-08 09:16:31 +0200)

----------------------------------------------------------------
fbdev changes for 3.19

* support for mx6sl and mx6sx
* OMAP HDMI audio rewrite to make it finally work
* OMAP video PLL work to prepare for new DRA7xx SoCs
* simplefb DT related improvements

----------------------------------------------------------------
Alexey Khoroshilov (1):
      m501fb: don't return zero on failure path in sm501fb_probe()

Archit Taneja (7):
      OMAPDSS: DPI: Use DPI driver data
      OMAPDSS: DPI: Allocate driver data
      OMAPDSS: DPI: Store dpi_data pointer in the DT port's data
      OMAPDSS: DSS: init dss ports cleanly
      OMAPDSS: DT: Get source endpoint by matching reg-id
      OMAPDSS: DPI: Add support for multiple instances
      OMAPDSS: DSS: add a param to dpi_select_source which specifies it's port number

Fabio Estevam (1):

156 more lines

On Thu, Dec 11, 2014 at 5:41 AM, Tomi Valkeinen [off-list ref] wrote:

Please pull fbdev changes for 3.19.

Ugh. I've pulled it, but I'm not a huge fan of commit 6d09dc6b74ca
("of.h: Keep extern declaration of of_* variables when !CONFIG_OF").

I guess it works, but it ends up delaying any failures from compile
time to link time, and the linker error messages likely won't be
great.

So I'm cc'ing the OF people and Rafael (who worked on OF/ACPI
unification) to see if they have comments, preferences, or other ways
to solve this.

Quite frankly, to me it smells like non-OF builds should just have an
empty "for_each_child_of_node ()" define instead of playing games with
externs that then end up not existing, and depending on the compiler
DTRT.

Comments?

                      Linus

On Thursday, December 11, 2014 12:55:28 PM Linus Torvalds wrote:

On Thu, Dec 11, 2014 at 5:41 AM, Tomi Valkeinen [off-list ref] wrote:

quoted

Please pull fbdev changes for 3.19.

Ugh. I've pulled it, but I'm not a huge fan of commit 6d09dc6b74ca
("of.h: Keep extern declaration of of_* variables when !CONFIG_OF").

I guess it works, but it ends up delaying any failures from compile
time to link time, and the linker error messages likely won't be
great.

So I'm cc'ing the OF people and Rafael (who worked on OF/ACPI
unification) to see if they have comments, preferences, or other ways
to solve this.

Quite frankly, to me it smells like non-OF builds should just have an
empty "for_each_child_of_node ()" define instead of playing games with
externs that then end up not existing, and depending on the compiler
DTRT.

Comments?

"for_each_child_of_node ()" is not a problem here AFAICS, because in the
example from the commit changelog the compiler would complain on the
of_chosen instance in the "if ()" statement already anyway if I'm not mistaken.

It wants all of the code in the given block to make sense even if that
block will be optimized away going forward.  That's not specific to CONFIG_OF
too.

I stumbled over that a couple of times and I don't see a clean and simple way
to work around it at the moment.  In the cases I dealt with it was sufficient
to use static inlines that were defined to return NULL (or equivalent) when
the symbol in question was not defined.

Rafael

On Thu, Dec 11, 2014 at 4:58 PM, Rafael J. Wysocki [off-list ref] wrote:

On Thursday, December 11, 2014 12:55:28 PM Linus Torvalds wrote:

quoted

On Thu, Dec 11, 2014 at 5:41 AM, Tomi Valkeinen [off-list ref] wrote:

quoted

Please pull fbdev changes for 3.19.

Ugh. I've pulled it, but I'm not a huge fan of commit 6d09dc6b74ca
("of.h: Keep extern declaration of of_* variables when !CONFIG_OF").

I guess it works, but it ends up delaying any failures from compile
time to link time, and the linker error messages likely won't be
great.

So I'm cc'ing the OF people and Rafael (who worked on OF/ACPI
unification) to see if they have comments, preferences, or other ways
to solve this.

Quite frankly, to me it smells like non-OF builds should just have an
empty "for_each_child_of_node ()" define instead of playing games with
externs that then end up not existing, and depending on the compiler
DTRT.

Comments?

"for_each_child_of_node ()" is not a problem here AFAICS, because in the
example from the commit changelog the compiler would complain on the
of_chosen instance in the "if ()" statement already anyway if I'm not mistaken.

Really, the "if" should be completely removed here.
for_each_child_of_node should do the right thing for !OF or if
of_chosen is NULL already. Since for_each_child_of_node relies on it's
helper function to get optimized away we need of_chosen defined to
something.

I believe Linus' suggestion was we could have an empty
for_each_child_of_node() define, but we've moved away from that to
simplify the of.h header and avoid multiple definitions. Doing that
has it's own issues. Fixing up !OF problems has been somewhat painful
as we've converted ARM and people failed to test that.

Rob

On Thursday, December 11, 2014 06:59:34 PM Rob Herring wrote:

On Thu, Dec 11, 2014 at 4:58 PM, Rafael J. Wysocki [off-list ref] wrote:

quoted

On Thursday, December 11, 2014 12:55:28 PM Linus Torvalds wrote:

quoted

On Thu, Dec 11, 2014 at 5:41 AM, Tomi Valkeinen [off-list ref] wrote:

quoted

Please pull fbdev changes for 3.19.

Ugh. I've pulled it, but I'm not a huge fan of commit 6d09dc6b74ca
("of.h: Keep extern declaration of of_* variables when !CONFIG_OF").

I guess it works, but it ends up delaying any failures from compile
time to link time, and the linker error messages likely won't be
great.

So I'm cc'ing the OF people and Rafael (who worked on OF/ACPI
unification) to see if they have comments, preferences, or other ways
to solve this.

Quite frankly, to me it smells like non-OF builds should just have an
empty "for_each_child_of_node ()" define instead of playing games with
externs that then end up not existing, and depending on the compiler
DTRT.

Comments?

"for_each_child_of_node ()" is not a problem here AFAICS, because in the
example from the commit changelog the compiler would complain on the
of_chosen instance in the "if ()" statement already anyway if I'm not mistaken.

Really, the "if" should be completely removed here.
for_each_child_of_node should do the right thing for !OF or if
of_chosen is NULL already.

This still is an example of a common pattern:

<statement optimized away for CONFIG_BLAH unset> {
	<some code>
}

Now, if you use variables defined only for CONFIG_BLAH set in the above (block
or statement), you'll get compile errors for !CONFIG_BLAH.

There is a limited choice of what can be done to avoid those errors:
 (a) Put the whole code in question under #ifdef CONFIG_BLAH (defeats the
     purpose of the entire exercise).
 (b) Define the variables unconditionally (wasted memory for !CONFIG_BLAH).
 (c) Wrap the variables in static inline functions that will be empty for
     !CONFIG_BLAH ("one more level of indirection" approach).
 (d) Do dirty tricks like in commit 6d09dc6b74ca.

Are there any more options that I'm overlooking?  If not, (a) and (b) are
unattractive, so the real choice seems to be between (c) and (d) to me.

Rafael

Hi!

Please pull fbdev changes for 3.19.

 Tomi

v3.19-rc0 breaks video on my n900.

Archit Taneja (7):
      OMAPDSS: DPI: Use DPI driver data
      OMAPDSS: DPI: Allocate driver data
      OMAPDSS: DPI: Store dpi_data pointer in the DT port's data
      OMAPDSS: DSS: init dss ports cleanly
      OMAPDSS: DT: Get source endpoint by matching reg-id
      OMAPDSS: DPI: Add support for multiple instances
      OMAPDSS: DSS: add a param to dpi_select_source which specifies
      it's port number

And I have these in my tree, so I should have latest fixes. Any ideas
what I should try?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Sat 2014-12-20 22:01:25, Pavel Machek wrote:

Hi!

quoted

Please pull fbdev changes for 3.19.

 Tomi

v3.19-rc0 breaks video on my n900.

quoted

Archit Taneja (7):
      OMAPDSS: DPI: Use DPI driver data
      OMAPDSS: DPI: Allocate driver data
      OMAPDSS: DPI: Store dpi_data pointer in the DT port's data
      OMAPDSS: DSS: init dss ports cleanly
      OMAPDSS: DT: Get source endpoint by matching reg-id
      OMAPDSS: DPI: Add support for multiple instances
      OMAPDSS: DSS: add a param to dpi_select_source which specifies
      it's port number

And I have these in my tree, so I should have latest fixes. Any ideas
what I should try?

I test-merged 3315764efceaccfb02c7d4c99ef8eed6716cd861, and boom,
video is gone.

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Sat 2014-12-20 22:20:27, Pavel Machek wrote:

On Sat 2014-12-20 22:01:25, Pavel Machek wrote:

quoted

Hi!

quoted

Please pull fbdev changes for 3.19.

 Tomi

v3.19-rc0 breaks video on my n900.

quoted

Archit Taneja (7):
      OMAPDSS: DPI: Use DPI driver data
      OMAPDSS: DPI: Allocate driver data
      OMAPDSS: DPI: Store dpi_data pointer in the DT port's data
      OMAPDSS: DSS: init dss ports cleanly
      OMAPDSS: DT: Get source endpoint by matching reg-id
      OMAPDSS: DPI: Add support for multiple instances
      OMAPDSS: DSS: add a param to dpi_select_source which specifies
      it's port number

And I have these in my tree, so I should have latest fixes. Any ideas
what I should try?

I test-merged 3315764efceaccfb02c7d4c99ef8eed6716cd861, and boom,
video is gone.

I reverted
4b4123f0c7b02f7cf1a3189f967f079197578c3a..9051909e451a0368c95ccf74562adb53fd2719f8
in 3.19, and voila, video is back.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Sat 2014-12-20 22:57:18, Pavel Machek wrote:

On Sat 2014-12-20 22:20:27, Pavel Machek wrote:

quoted

On Sat 2014-12-20 22:01:25, Pavel Machek wrote:

quoted

Hi!

quoted

Please pull fbdev changes for 3.19.

 Tomi

v3.19-rc0 breaks video on my n900.

quoted

Archit Taneja (7):
      OMAPDSS: DPI: Use DPI driver data
      OMAPDSS: DPI: Allocate driver data
      OMAPDSS: DPI: Store dpi_data pointer in the DT port's data
      OMAPDSS: DSS: init dss ports cleanly
      OMAPDSS: DT: Get source endpoint by matching reg-id
      OMAPDSS: DPI: Add support for multiple instances
      OMAPDSS: DSS: add a param to dpi_select_source which specifies
      it's port number

And I have these in my tree, so I should have latest fixes. Any ideas
what I should try?

I test-merged 3315764efceaccfb02c7d4c99ef8eed6716cd861, and boom,
video is gone.

I reverted
4b4123f0c7b02f7cf1a3189f967f079197578c3a..9051909e451a0368c95ccf74562adb53fd2719f8
in 3.19, and voila, video is back.

Tomi?

Your merge causes regression on my hardware. I'd expect some
communication from you. If you don't have time right now, can we
revert the merge until its fixed?

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi,

On 23/12/14 13:12, Pavel Machek wrote:

quoted

quoted

I test-merged 3315764efceaccfb02c7d4c99ef8eed6716cd861, and boom,
video is gone.

I reverted
4b4123f0c7b02f7cf1a3189f967f079197578c3a..9051909e451a0368c95ccf74562adb53fd2719f8
in 3.19, and voila, video is back.

Tomi?

Your merge causes regression on my hardware. I'd expect some
communication from you. If you don't have time right now, can we
revert the merge until its fixed?

I've posted a fix on the "n900 regressions" thread.

 Tomi