Hi,
On Mon, May 19, 2014 at 09:57:18PM +0300, Tomi Valkeinen wrote:
quoted
3. Having to maintain a database in kernel of display mappings separately
in addition to the .dts files.
Yes, that's slightly annoying. Not really a big burden, though, as it's
quite rare to get a new encoder or panel driver.
I wonder if the "omapdss," prefix could be added to *all* remote
endpoints seen by omapdss. Pseudocode:
for each port in dss {
for each endpoint in port {
panel = get_phandle(endpoint, "remote-endpoint");
/* only add prefix if it's not already there (kexec) */
if (panel.compatible != "omapdss,.*")
panel.compatible = "omapdss," + panel.compatible;
}
}
-- Sebastian
On 20/05/14 07:57, Sebastian Reichel wrote:
Hi,
On Mon, May 19, 2014 at 09:57:18PM +0300, Tomi Valkeinen wrote:
quoted
quoted
3. Having to maintain a database in kernel of display mappings separately
in addition to the .dts files.
Yes, that's slightly annoying. Not really a big burden, though, as it's
quite rare to get a new encoder or panel driver.
I wonder if the "omapdss," prefix could be added to *all* remote
endpoints seen by omapdss. Pseudocode:
for each port in dss {
for each endpoint in port {
panel = get_phandle(endpoint, "remote-endpoint");
/* only add prefix if it's not already there (kexec) */
if (panel.compatible != "omapdss,.*")
panel.compatible = "omapdss," + panel.compatible;
}
}
Hmm, yes, I think that would work. It would remove the need for the
database, but the code would be slightly more complex as we'd need to
travel through the graph, not just the nodes that are directly connected
to omapdss. I need to try this approach also.
Tomi
Ps. Sorry for misspelling your name, twice. If I recall right, I even
checked if your name is written with an 'a' or an 'e', but somehow still
managed to get it wrong.