public inbox for linux-tegra@vger.kernel.org
 help / color / mirror / Atom feed
* Re: Naming convention DSI + device tree
       [not found]     ` <20130516071537.GA13573-cEukqlNQfh4fv37vnLkPlQ@public.gmane.org>
@ 2013-05-16 18:17       ` Stephen Warren
  2013-05-16 19:50         ` David Lanzendörfer
       [not found]         ` <519522C1.5010107-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
  0 siblings, 2 replies; 6+ messages in thread
From: Stephen Warren @ 2013-05-16 18:17 UTC (permalink / raw)
  To: David Lanzendörfer
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Alexandre Courbot,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Naming convention DSI + device tree
  2013-05-16 18:17       ` Naming convention DSI + device tree Stephen Warren
@ 2013-05-16 19:50         ` David Lanzendörfer
       [not found]         ` <519522C1.5010107-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
  1 sibling, 0 replies; 6+ messages in thread
From: David Lanzendörfer @ 2013-05-16 19:50 UTC (permalink / raw)
  To: Stephen Warren
  Cc: linux-tegra@vger.kernel.org, Alexandre Courbot, linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 1018 bytes --]

> No, we haven't yet posted DSI support upstream.
Ok.

> 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...
Ok. If there's an API already flying around somewhere, which will
be posted to upstream at some point of time, and won't change drastically
anymore I can work with it. 

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

> 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.
Ok. Thank you very much!
The best would be a patchset for CDF against linux-next (which will most
likely be the case anyway) in order to track the changes and post my own
changes upstream as soon as CDF is in next.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Naming convention DSI + device tree
       [not found]         ` <519522C1.5010107-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
@ 2013-05-17  5:36           ` Alex Courbot
       [not found]             ` <5195C1E2.4020009-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 6+ messages in thread
From: Alex Courbot @ 2013-05-17  5:36 UTC (permalink / raw)
  To: Stephen Warren
  Cc: David Lanzendörfer,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Laurent Pinchart

On 05/17/2013 03:17 AM, Stephen Warren wrote:
>> 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.

Current version is RFC v2 - I know Laurent is working on a v3, but it is 
taking some time. It will probably differ considerably from v2, so be 
warned if you use it.

Still, if you want to play around with the CDF, you can have a look at 
the tegra-cdf branch of my github repo: 
https://github.com/Gnurou/linux/commits/tegra-cdf

It was kind of old so I rebased it on top of 3.10rc1. It includes the 
CDF v2 patch, adds CDF support to the tegra-drm driver, and also 
implements a driver for the Tegra 2-based Ventana panel. It's pretty 
straightforward to read so I guess you can use that as a guide.

I checked whether the rebase worked and it does - you just need to 
enable host1x/tegradrm support on top of the default settings (Stephen, 
why aren't these enabled by default?)

So long story short, CDF works well and is small enough to be easy to 
maintain out-of-tree. A proper panel framework is desperately needed in 
the kernel, so I hope it will move forward soon.

Hope this helps,
Alex.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Naming convention DSI + device tree
       [not found]             ` <5195C1E2.4020009-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
@ 2013-05-17 19:39               ` Stephen Warren
  2013-05-22  6:24               ` Mark Zhang
  1 sibling, 0 replies; 6+ messages in thread
From: Stephen Warren @ 2013-05-17 19:39 UTC (permalink / raw)
  To: Alex Courbot
  Cc: David Lanzendörfer,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Laurent Pinchart

On 05/16/2013 11:36 PM, Alex Courbot wrote:
...
> I checked whether the rebase worked and it does - you just need to
> enable host1x/tegradrm support on top of the default settings (Stephen,
> why aren't these enabled by default?)

I guess it just got overlooked. I see CONFIG_DRM is on though; perhaps
the default for the Tegra DRM driver changed in Kconfig. Feel free to
send a patch to tegra_defconfig.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Naming convention DSI + device tree
       [not found]             ` <5195C1E2.4020009-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
  2013-05-17 19:39               ` Stephen Warren
@ 2013-05-22  6:24               ` Mark Zhang
  2013-05-23  9:55                 ` Alex Courbot
  1 sibling, 1 reply; 6+ messages in thread
From: Mark Zhang @ 2013-05-22  6:24 UTC (permalink / raw)
  To: Alex Courbot
  Cc: Stephen Warren, David Lanzendörfer,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Laurent Pinchart

Cool. Alex, do you know any updates on DSI part of CDF? I recall few
months ago, Laurent wrote mail to share some infos about the CDF
discussions, and it mentioned that the DSI will be considered in next
version of CDF... you know, for t114, the DSI support is a must.

Mark
On 05/17/2013 01:36 PM, Alex Courbot wrote:
> On 05/17/2013 03:17 AM, Stephen Warren wrote:
>>> 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.
> 
> Current version is RFC v2 - I know Laurent is working on a v3, but it is
> taking some time. It will probably differ considerably from v2, so be
> warned if you use it.
> 
> Still, if you want to play around with the CDF, you can have a look at
> the tegra-cdf branch of my github repo:
> https://github.com/Gnurou/linux/commits/tegra-cdf
> 
> It was kind of old so I rebased it on top of 3.10rc1. It includes the
> CDF v2 patch, adds CDF support to the tegra-drm driver, and also
> implements a driver for the Tegra 2-based Ventana panel. It's pretty
> straightforward to read so I guess you can use that as a guide.
> 
> I checked whether the rebase worked and it does - you just need to
> enable host1x/tegradrm support on top of the default settings (Stephen,
> why aren't these enabled by default?)
> 
> So long story short, CDF works well and is small enough to be easy to
> maintain out-of-tree. A proper panel framework is desperately needed in
> the kernel, so I hope it will move forward soon.
> 
> Hope this helps,
> Alex.
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Naming convention DSI + device tree
  2013-05-22  6:24               ` Mark Zhang
@ 2013-05-23  9:55                 ` Alex Courbot
  0 siblings, 0 replies; 6+ messages in thread
From: Alex Courbot @ 2013-05-23  9:55 UTC (permalink / raw)
  To: Mark Zhang
  Cc: linux-tegra@vger.kernel.org, David Lanzendörfer,
	Laurent Pinchart, linux-arm-kernel@lists.infradead.org,
	Stephen Warren

On 05/22/2013 03:24 PM, Mark Zhang wrote:
> Cool. Alex, do you know any updates on DSI part of CDF? I recall few
> months ago, Laurent wrote mail to share some infos about the CDF
> discussions, and it mentioned that the DSI will be considered in next
> version of CDF... you know, for t114, the DSI support is a must.

I will make sure to discuss this detail with Laurent as he comes for 
LinuxCon next week. ;)

Alex.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2013-05-23  9:55 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20130514181745.GA2762@mail.o2s.ch>
     [not found] ` <51940C22.4050802@wwwdotorg.org>
     [not found]   ` <20130516071537.GA13573@mail.o2s.ch>
     [not found]     ` <20130516071537.GA13573-cEukqlNQfh4fv37vnLkPlQ@public.gmane.org>
2013-05-16 18:17       ` Naming convention DSI + device tree Stephen Warren
2013-05-16 19:50         ` David Lanzendörfer
     [not found]         ` <519522C1.5010107-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
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-22  6:24               ` Mark Zhang
2013-05-23  9:55                 ` Alex Courbot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox