From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: "David Lanzendörfer" <david.lanzendoerfer-Z7Kmv9EsliU@public.gmane.org>
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Alexandre Courbot
<acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: Naming convention DSI + device tree
Date: Thu, 16 May 2013 12:17:37 -0600 [thread overview]
Message-ID: <519522C1.5010107@wwwdotorg.org> (raw)
In-Reply-To: <20130516071537.GA13573-cEukqlNQfh4fv37vnLkPlQ@public.gmane.org>
On 05/16/2013 01:15 AM, David Lanzendörfer wrote:
> On Wed, May 15, 2013 at 04:28:50PM -0600, Stephen Warren wrote:
>> On 05/14/2013 12:17 PM, David Lanzendörfer wrote:
>>> Hello I have the following issue: In order to make the DSI
>>> controller react at all,
>>
>> Hmm. In the upstream kernel, we don't even have a DSI driver at
>> all for Tegra, so control over the panel itself is likely the
>> least of your worries for now.
>
> Is there a patch set pending for merge into upstream which will
> provide this support? And if yes, where can I find these pending
> patches? I'd like to build up my code based on already existing
> work which is expected to be in upstream at some later point of
> time.
No, we haven't yet posted DSI support upstream.
>>> I need to pass him a certain combination of pin states. Until
>>> now within the code of the original android kernel which was
>>> using board files this has just been done by doing bit
>>> banging.
>>>
>>> namely: gpio_set_value(tf201_lvds_shutdown, 1); ... Now with a
>>> device tree comes the question: Where should I put this?
>>
>> Likely, you will need to create a DT binding that represents the
>> particular panel model that you have, and make the Tegra display
>> controller node refer to that panel node. The panel node would
>> need properties to describe the various GPIOs used to control the
>> panel. Then, you'd want to write a panel-specific driver that
>> handles that device tree node.
>
> That was my thought too. Where should I put this panel-specific
> driver?
Honestly, I'm not sure. I assume (and it is just an assumption) that
if you look at the CDF patches, you should find some examples of panel
drivers that use it, although perhaps there aren't any yet...
>> All of this will likely need to be integrated with the upcoming
>> Common Display Framework.
>
> Is this upcoming CDF included within your "linux-next_common"
> branch?
No. That branch of mine is basd on linux-next, so whatever is in
linux-next is in my branch, and I certainly haven't applied the CDF
locally.
I believe the CDF has been posted to various mailing lists a few
times, but it isn't checked in yet since there isn't a final version.
I CC'd Alex; he might know the status better than me.
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: Naming convention DSI + device tree
Date: Thu, 16 May 2013 12:17:37 -0600 [thread overview]
Message-ID: <519522C1.5010107@wwwdotorg.org> (raw)
In-Reply-To: <20130516071537.GA13573@mail.o2s.ch>
On 05/16/2013 01:15 AM, David Lanzend?rfer wrote:
> On Wed, May 15, 2013 at 04:28:50PM -0600, Stephen Warren wrote:
>> On 05/14/2013 12:17 PM, David Lanzend?rfer wrote:
>>> Hello I have the following issue: In order to make the DSI
>>> controller react at all,
>>
>> Hmm. In the upstream kernel, we don't even have a DSI driver at
>> all for Tegra, so control over the panel itself is likely the
>> least of your worries for now.
>
> Is there a patch set pending for merge into upstream which will
> provide this support? And if yes, where can I find these pending
> patches? I'd like to build up my code based on already existing
> work which is expected to be in upstream at some later point of
> time.
No, we haven't yet posted DSI support upstream.
>>> I need to pass him a certain combination of pin states. Until
>>> now within the code of the original android kernel which was
>>> using board files this has just been done by doing bit
>>> banging.
>>>
>>> namely: gpio_set_value(tf201_lvds_shutdown, 1); ... Now with a
>>> device tree comes the question: Where should I put this?
>>
>> Likely, you will need to create a DT binding that represents the
>> particular panel model that you have, and make the Tegra display
>> controller node refer to that panel node. The panel node would
>> need properties to describe the various GPIOs used to control the
>> panel. Then, you'd want to write a panel-specific driver that
>> handles that device tree node.
>
> That was my thought too. Where should I put this panel-specific
> driver?
Honestly, I'm not sure. I assume (and it is just an assumption) that
if you look at the CDF patches, you should find some examples of panel
drivers that use it, although perhaps there aren't any yet...
>> All of this will likely need to be integrated with the upcoming
>> Common Display Framework.
>
> Is this upcoming CDF included within your "linux-next_common"
> branch?
No. That branch of mine is basd on linux-next, so whatever is in
linux-next is in my branch, and I certainly haven't applied the CDF
locally.
I believe the CDF has been posted to various mailing lists a few
times, but it isn't checked in yet since there isn't a final version.
I CC'd Alex; he might know the status better than me.
next prev parent reply other threads:[~2013-05-16 18:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-14 18:17 Naming convention DSI + device tree David Lanzendörfer
2013-05-15 22:28 ` Stephen Warren
2013-05-16 7:15 ` David Lanzendörfer
[not found] ` <20130516071537.GA13573-cEukqlNQfh4fv37vnLkPlQ@public.gmane.org>
2013-05-16 18:17 ` Stephen Warren [this message]
2013-05-16 18:17 ` Stephen Warren
2013-05-16 19:50 ` David Lanzendörfer
2013-05-16 19:50 ` David Lanzendörfer
[not found] ` <519522C1.5010107-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-05-17 5:36 ` Alex Courbot
2013-05-17 5:36 ` Alex Courbot
[not found] ` <5195C1E2.4020009-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-05-17 19:39 ` Stephen Warren
2013-05-17 19:39 ` Stephen Warren
2013-05-22 6:24 ` Mark Zhang
2013-05-22 6:24 ` Mark Zhang
2013-05-23 9:55 ` Alex Courbot
2013-05-23 9:55 ` Alex Courbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=519522C1.5010107@wwwdotorg.org \
--to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
--cc=acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=david.lanzendoerfer-Z7Kmv9EsliU@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.