Naming convention DSI + device tree

Naming convention DSI + device tree

[David Lanzendörfer]

Hello
I have the following issue:
In order to make the DSI controller react at all, 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);
	mdelay(20);
	gpio_set_value(TEGRA_GPIO_PH0, 1);
	mdelay(10);
	gpio_set_value(TEGRA_GPIO_PH2, 1);
	mdelay(15);
	gpio_set_value(TEGRA_GPIO_PU2, 0);
	gpio_set_value(TEGRA_GPIO_PU2, 1);
	mdelay(10);
	gpio_set_value(TEGRA_GPIO_PU2, 0);
	mdelay(10);
	gpio_set_value(TEGRA_GPIO_PU2, 1);
	mdelay(15);

Now with a device tree comes the question: Where should I put this?
Also because I don't have the schematics of the TF201 (for obvious reasons)
I won't be able to name the pin assignments of the DSI controller
in a generic driver correctly.
Would be neat if an ASUS engineer with the schematic at hand could
figure out what pins these are and could name the pin assignment.

best regards
David

Naming convention DSI + device tree

[Stephen Warren]

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.

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

All of this will likely need to be integrated with the upcoming Common
Display Framework.

Naming convention DSI + device tree

[David Lanzendörfer]

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.

> > 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?

> 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?

best regards
David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130516/aa8223d1/attachment.sig>

Naming convention DSI + device tree

[Stephen Warren]

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.

Naming convention DSI + device tree

[David Lanzendörfer]

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130516/e5a0e597/attachment.sig>

Naming convention DSI + device tree

[Alex Courbot]

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.

Naming convention DSI + device tree

[Stephen Warren]

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.

Naming convention DSI + device tree

[Mark Zhang]

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 at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Naming convention DSI + device tree

[Alex Courbot]

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.