Tegra board file deprecation schedule

Tegra board file deprecation schedule

[Stephen Warren]

Eventually, Tegra support will become device tree only in the mainline
kernel; arch/arm/mach-tegra/board* will be deleted.

I propose the following policy towards this goal: I'd like to maintain
the board files until the relevant device tree file has the same level
of functionality. Once that is achieved, and a Linus kernel is release
with full support for the board via device tree, the board files can be
deleted from the next kernel release.

Does anyone have any issues with this?

The device tree conversion status is:

Cardhu/Ventana:

None; already device tree only

Seaboard:

Kaen and Wario board variants are not explicitly supported via device
tree. However, the differences are almost entirely minor (at least as
far as the current features supported in board-seaboard*), so anyone
wishing to use those board variants could easily create their own device
tree files. I plan to ignore Kaen/Wario and delete board-seaboard* in
3.6 unless someone objects.

Harmony:

Missing support for TPS6586x regulator, and PCI-Express controller.
Thierry is working on this. I hope this support will be ready to be
merged for 3.6, and hence board-harmony* can be deleted in 3.7.

TrimSlice:

Missing RTC and Micro-SD slot support. I've sent patches for this, which
will be merged today.

Missing audio support. I sent patches for this today. I hope they'll be
merged for 3.5.

Missing PCI-Express support; status above.

I hope board-trimslice* can be deleted in 3.7.

Paz00/Toshiba AC100:

Missing rfkill button support. Defining a good binding for this might
prove challenging. Marc Dietrich started work on this a while back. I
pinged him to see if he intends to continue this work.

This is probably the long-pole for completely removing board files,
unless we ignore the rfkill feature and delete the board files anyway.

Tegra board file deprecation schedule

[Stephen Warren]

Eventually, Tegra support will become device tree only in the mainline
kernel; arch/arm/mach-tegra/board* will be deleted.

I propose the following policy towards this goal: I'd like to maintain
the board files until the relevant device tree file has the same level
of functionality. Once that is achieved, and a Linus kernel is release
with full support for the board via device tree, the board files can be
deleted from the next kernel release.

Does anyone have any issues with this?

The device tree conversion status is:

Cardhu/Ventana:

None; already device tree only

Seaboard:

Kaen and Wario board variants are not explicitly supported via device
tree. However, the differences are almost entirely minor (at least as
far as the current features supported in board-seaboard*), so anyone
wishing to use those board variants could easily create their own device
tree files. I plan to ignore Kaen/Wario and delete board-seaboard* in
3.6 unless someone objects.

Harmony:

Missing support for TPS6586x regulator, and PCI-Express controller.
Thierry is working on this. I hope this support will be ready to be
merged for 3.6, and hence board-harmony* can be deleted in 3.7.

TrimSlice:

Missing RTC and Micro-SD slot support. I've sent patches for this, which
will be merged today.

Missing audio support. I sent patches for this today. I hope they'll be
merged for 3.5.

Missing PCI-Express support; status above.

I hope board-trimslice* can be deleted in 3.7.

Paz00/Toshiba AC100:

Missing rfkill button support. Defining a good binding for this might
prove challenging. Marc Dietrich started work on this a while back. I
pinged him to see if he intends to continue this work.

This is probably the long-pole for completely removing board files,
unless we ignore the rfkill feature and delete the board files anyway.

Re: Tegra board file deprecation schedule

[Olof Johansson]

On Fri, Apr 27, 2012 at 2:24 PM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
> Eventually, Tegra support will become device tree only in the mainline
> kernel; arch/arm/mach-tegra/board* will be deleted.
>
> I propose the following policy towards this goal: I'd like to maintain
> the board files until the relevant device tree file has the same level
> of functionality. Once that is achieved, and a Linus kernel is release
> with full support for the board via device tree, the board files can be
> deleted from the next kernel release.
>
> Does anyone have any issues with this?

Sounds great, but I think you can be more aggressive than this; no
need to keep the non-DT board alive for the final release.

> The device tree conversion status is:
>
> Cardhu/Ventana:
>
> None; already device tree only
>
> Seaboard:
>
> Kaen and Wario board variants are not explicitly supported via device
> tree. However, the differences are almost entirely minor (at least as
> far as the current features supported in board-seaboard*), so anyone
> wishing to use those board variants could easily create their own device
> tree files. I plan to ignore Kaen/Wario and delete board-seaboard* in
> 3.6 unless someone objects.

Wario is no longer an active platform and can be completely removed;
I'll post patches for this.

Kaen is somewhat active, but I can send a device tree for it;
definitely ok to sunset before it's in since we can carry it locally
in our downstream kernel tree if needed.

>
> Harmony:
>
> Missing support for TPS6586x regulator, and PCI-Express controller.
> Thierry is working on this. I hope this support will be ready to be
> merged for 3.6, and hence board-harmony* can be deleted in 3.7.
>
> TrimSlice:
>
> Missing RTC and Micro-SD slot support. I've sent patches for this, which
> will be merged today.
>
> Missing audio support. I sent patches for this today. I hope they'll be
> merged for 3.5.
>
> Missing PCI-Express support; status above.
>
> I hope board-trimslice* can be deleted in 3.7.
>
> Paz00/Toshiba AC100:
>
> Missing rfkill button support. Defining a good binding for this might
> prove challenging. Marc Dietrich started work on this a while back. I
> pinged him to see if he intends to continue this work.
>
> This is probably the long-pole for completely removing board files,
> unless we ignore the rfkill feature and delete the board files anyway.

if this is the only thing holding it up sunsetting all non-DT boards
on tegra then I suggest just adding a one-time runtime test that adds
a platform device on that device tree platform. As long as there
aren't more of them creeping in over time that should be OK.



-Olof

Tegra board file deprecation schedule

[Olof Johansson]

On Fri, Apr 27, 2012 at 2:24 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> Eventually, Tegra support will become device tree only in the mainline
> kernel; arch/arm/mach-tegra/board* will be deleted.
>
> I propose the following policy towards this goal: I'd like to maintain
> the board files until the relevant device tree file has the same level
> of functionality. Once that is achieved, and a Linus kernel is release
> with full support for the board via device tree, the board files can be
> deleted from the next kernel release.
>
> Does anyone have any issues with this?

Sounds great, but I think you can be more aggressive than this; no
need to keep the non-DT board alive for the final release.

> The device tree conversion status is:
>
> Cardhu/Ventana:
>
> None; already device tree only
>
> Seaboard:
>
> Kaen and Wario board variants are not explicitly supported via device
> tree. However, the differences are almost entirely minor (at least as
> far as the current features supported in board-seaboard*), so anyone
> wishing to use those board variants could easily create their own device
> tree files. I plan to ignore Kaen/Wario and delete board-seaboard* in
> 3.6 unless someone objects.

Wario is no longer an active platform and can be completely removed;
I'll post patches for this.

Kaen is somewhat active, but I can send a device tree for it;
definitely ok to sunset before it's in since we can carry it locally
in our downstream kernel tree if needed.

>
> Harmony:
>
> Missing support for TPS6586x regulator, and PCI-Express controller.
> Thierry is working on this. I hope this support will be ready to be
> merged for 3.6, and hence board-harmony* can be deleted in 3.7.
>
> TrimSlice:
>
> Missing RTC and Micro-SD slot support. I've sent patches for this, which
> will be merged today.
>
> Missing audio support. I sent patches for this today. I hope they'll be
> merged for 3.5.
>
> Missing PCI-Express support; status above.
>
> I hope board-trimslice* can be deleted in 3.7.
>
> Paz00/Toshiba AC100:
>
> Missing rfkill button support. Defining a good binding for this might
> prove challenging. Marc Dietrich started work on this a while back. I
> pinged him to see if he intends to continue this work.
>
> This is probably the long-pole for completely removing board files,
> unless we ignore the rfkill feature and delete the board files anyway.

if this is the only thing holding it up sunsetting all non-DT boards
on tegra then I suggest just adding a one-time runtime test that adds
a platform device on that device tree platform. As long as there
aren't more of them creeping in over time that should be OK.



-Olof

Re: Tegra board file deprecation schedule

[Stephen Warren]

On 04/27/2012 03:39 PM, Olof Johansson wrote:
> On Fri, Apr 27, 2012 at 2:24 PM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
>> Eventually, Tegra support will become device tree only in the mainline
>> kernel; arch/arm/mach-tegra/board* will be deleted.
>>
>> I propose the following policy towards this goal: I'd like to maintain
>> the board files until the relevant device tree file has the same level
>> of functionality. Once that is achieved, and a Linus kernel is release
>> with full support for the board via device tree, the board files can be
>> deleted from the next kernel release.
...
> Sounds great, but I think you can be more aggressive than this; no
> need to keep the non-DT board alive for the final release.

I'm slightly hesitant not to have some overlap. But then again, I very
rarely use non-DT these days anyway, so it's not like it gets tested
much, unless anyone else is doing it silently.

>> The device tree conversion status is:
...
> if this is the only thing holding it up sunsetting all non-DT boards
> on tegra then I suggest just adding a one-time runtime test that adds
> a platform device on that device tree platform. As long as there
> aren't more of them creeping in over time that should be OK.

The only one sticking point might be that the Harmony regulator
initialization needs to wait for the regulator driver to be probed, but
happen before the PCIe driver is registers. Perhaps we could hook up
some temporary bus notifiers to handle that. But since PCIe will likely
be fixed in 3.6, we could probably just wait for that on Harmony.

Other than that, it's probably all very easy. I'll work on some patches
and maybe we can at least bring in the TrimSlice and Paz00 schedule.

Tegra board file deprecation schedule

[Stephen Warren]

On 04/27/2012 03:39 PM, Olof Johansson wrote:
> On Fri, Apr 27, 2012 at 2:24 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> Eventually, Tegra support will become device tree only in the mainline
>> kernel; arch/arm/mach-tegra/board* will be deleted.
>>
>> I propose the following policy towards this goal: I'd like to maintain
>> the board files until the relevant device tree file has the same level
>> of functionality. Once that is achieved, and a Linus kernel is release
>> with full support for the board via device tree, the board files can be
>> deleted from the next kernel release.
...
> Sounds great, but I think you can be more aggressive than this; no
> need to keep the non-DT board alive for the final release.

I'm slightly hesitant not to have some overlap. But then again, I very
rarely use non-DT these days anyway, so it's not like it gets tested
much, unless anyone else is doing it silently.

>> The device tree conversion status is:
...
> if this is the only thing holding it up sunsetting all non-DT boards
> on tegra then I suggest just adding a one-time runtime test that adds
> a platform device on that device tree platform. As long as there
> aren't more of them creeping in over time that should be OK.

The only one sticking point might be that the Harmony regulator
initialization needs to wait for the regulator driver to be probed, but
happen before the PCIe driver is registers. Perhaps we could hook up
some temporary bus notifiers to handle that. But since PCIe will likely
be fixed in 3.6, we could probably just wait for that on Harmony.

Other than that, it's probably all very easy. I'll work on some patches
and maybe we can at least bring in the TrimSlice and Paz00 schedule.

Re: Tegra board file deprecation schedule

[Fabio Estevam]

On Fri, Apr 27, 2012 at 6:53 PM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:

> The only one sticking point might be that the Harmony regulator
> initialization needs to wait for the regulator driver to be probed, but
> happen before the PCIe driver is registers. Perhaps we could hook up
> some temporary bus notifiers to handle that. But since PCIe will likely
> be fixed in 3.6, we could probably just wait for that on Harmony.

Does EPROBE_DEFER help in this case?

Tegra board file deprecation schedule

[Fabio Estevam]

On Fri, Apr 27, 2012 at 6:53 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:

> The only one sticking point might be that the Harmony regulator
> initialization needs to wait for the regulator driver to be probed, but
> happen before the PCIe driver is registers. Perhaps we could hook up
> some temporary bus notifiers to handle that. But since PCIe will likely
> be fixed in 3.6, we could probably just wait for that on Harmony.

Does EPROBE_DEFER help in this case?

Re: Tegra board file deprecation schedule

[Stephen Warren]

On 04/27/2012 04:00 PM, Fabio Estevam wrote:
> On Fri, Apr 27, 2012 at 6:53 PM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
> 
>> The only one sticking point might be that the Harmony regulator
>> initialization needs to wait for the regulator driver to be probed, but
>> happen before the PCIe driver is registers. Perhaps we could hook up
>> some temporary bus notifiers to handle that. But since PCIe will likely
>> be fixed in 3.6, we could probably just wait for that on Harmony.
> 
> Does EPROBE_DEFER help in this case?

That's certainly the solution when everything is instantiated from
device tree, but I'm not sure it'll solve everything when doing the
regulator stuff from temporary code in the board file, which won't be
part of a driver probe.

Tegra board file deprecation schedule

[Stephen Warren]

On 04/27/2012 04:00 PM, Fabio Estevam wrote:
> On Fri, Apr 27, 2012 at 6:53 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> 
>> The only one sticking point might be that the Harmony regulator
>> initialization needs to wait for the regulator driver to be probed, but
>> happen before the PCIe driver is registers. Perhaps we could hook up
>> some temporary bus notifiers to handle that. But since PCIe will likely
>> be fixed in 3.6, we could probably just wait for that on Harmony.
> 
> Does EPROBE_DEFER help in this case?

That's certainly the solution when everything is instantiated from
device tree, but I'm not sure it'll solve everything when doing the
regulator stuff from temporary code in the board file, which won't be
part of a driver probe.

Re: Tegra board file deprecation schedule

[Marc Dietrich]

Hi,

On Friday 27 April 2012 14:39:35 Olof Johansson wrote:
> On Fri, Apr 27, 2012 at 2:24 PM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 
wrote:
> > Eventually, Tegra support will become device tree only in the mainline
> > kernel; arch/arm/mach-tegra/board* will be deleted.
> > 
> > I propose the following policy towards this goal: I'd like to maintain
> > the board files until the relevant device tree file has the same level
> > of functionality. Once that is achieved, and a Linus kernel is release
> > with full support for the board via device tree, the board files can be
> > deleted from the next kernel release.
> > 
> > Does anyone have any issues with this?
> 
> Sounds great, but I think you can be more aggressive than this; no
> need to keep the non-DT board alive for the final release.
> 
> > The device tree conversion status is:
> > 
> > Cardhu/Ventana:
> > 
> > None; already device tree only
> > 
> > Seaboard:
> > 
> > Kaen and Wario board variants are not explicitly supported via device
> > tree. However, the differences are almost entirely minor (at least as
> > far as the current features supported in board-seaboard*), so anyone
> > wishing to use those board variants could easily create their own device
> > tree files. I plan to ignore Kaen/Wario and delete board-seaboard* in
> > 3.6 unless someone objects.
> 
> Wario is no longer an active platform and can be completely removed;
> I'll post patches for this.
> 
> Kaen is somewhat active, but I can send a device tree for it;
> definitely ok to sunset before it's in since we can carry it locally
> in our downstream kernel tree if needed.
> 
> > Harmony:
> > 
> > Missing support for TPS6586x regulator, and PCI-Express controller.
> > Thierry is working on this. I hope this support will be ready to be
> > merged for 3.6, and hence board-harmony* can be deleted in 3.7.
> > 
> > TrimSlice:
> > 
> > Missing RTC and Micro-SD slot support. I've sent patches for this, which
> > will be merged today.
> > 
> > Missing audio support. I sent patches for this today. I hope they'll be
> > merged for 3.5.
> > 
> > Missing PCI-Express support; status above.
> > 
> > I hope board-trimslice* can be deleted in 3.7.
> > 
> > Paz00/Toshiba AC100:
> > 
> > Missing rfkill button support. Defining a good binding for this might
> > prove challenging. Marc Dietrich started work on this a while back. I
> > pinged him to see if he intends to continue this work.

I got no response after my last suggestion to add it below the corresponding 
usb controller [1]. It wasn't a clever idea anyway I think. So the best 
solution would be as Olof suggested to add it as a platform_device. See my 
original patch [2]. If this is ok, I can send a rebased version, and hope that 
the DT people accept it.

Some other things regarding board removal also came into my mind. First, is 
the sdhci order problem solved? Maybe I missed it, but it would be nice if we 
could give the internal emmc a device number of zero and the external reader a 
device number one. Currently it is oposite around and AFAIK device tree 
guaranties no special order unless you enforce it somehow.

Another (maybe a bit off-topic) thing that puzzels me is the how to assign the 
clock to the nvec. The device needs the clock (tegra-i2c.2) but there is no 
sane way to get it. I was thinking to add an device name alias (nvec = tegra-
i2c.2) to the board file so I can use clk_get(&pdev->dev, NULL) instead of 
clk_get_sys which seems to be unwanted. Is it possible to add a "clock" 
property to it?

Otherwise I'm fine with board file removal.

Marc

[1] http://permalink.gmane.org/gmane.linux.ports.tegra/3456
[2] http://permalink.gmane.org/gmane.linux.ports.tegra/3415


> > 
> > This is probably the long-pole for completely removing board files,
> > unless we ignore the rfkill feature and delete the board files anyway.
> 
> if this is the only thing holding it up sunsetting all non-DT boards
> on tegra then I suggest just adding a one-time runtime test that adds
> a platform device on that device tree platform. As long as there
> aren't more of them creeping in over time that should be OK.

Tegra board file deprecation schedule

[Marc Dietrich]

Hi,

On Friday 27 April 2012 14:39:35 Olof Johansson wrote:
> On Fri, Apr 27, 2012 at 2:24 PM, Stephen Warren <swarren@wwwdotorg.org> 
wrote:
> > Eventually, Tegra support will become device tree only in the mainline
> > kernel; arch/arm/mach-tegra/board* will be deleted.
> > 
> > I propose the following policy towards this goal: I'd like to maintain
> > the board files until the relevant device tree file has the same level
> > of functionality. Once that is achieved, and a Linus kernel is release
> > with full support for the board via device tree, the board files can be
> > deleted from the next kernel release.
> > 
> > Does anyone have any issues with this?
> 
> Sounds great, but I think you can be more aggressive than this; no
> need to keep the non-DT board alive for the final release.
> 
> > The device tree conversion status is:
> > 
> > Cardhu/Ventana:
> > 
> > None; already device tree only
> > 
> > Seaboard:
> > 
> > Kaen and Wario board variants are not explicitly supported via device
> > tree. However, the differences are almost entirely minor (at least as
> > far as the current features supported in board-seaboard*), so anyone
> > wishing to use those board variants could easily create their own device
> > tree files. I plan to ignore Kaen/Wario and delete board-seaboard* in
> > 3.6 unless someone objects.
> 
> Wario is no longer an active platform and can be completely removed;
> I'll post patches for this.
> 
> Kaen is somewhat active, but I can send a device tree for it;
> definitely ok to sunset before it's in since we can carry it locally
> in our downstream kernel tree if needed.
> 
> > Harmony:
> > 
> > Missing support for TPS6586x regulator, and PCI-Express controller.
> > Thierry is working on this. I hope this support will be ready to be
> > merged for 3.6, and hence board-harmony* can be deleted in 3.7.
> > 
> > TrimSlice:
> > 
> > Missing RTC and Micro-SD slot support. I've sent patches for this, which
> > will be merged today.
> > 
> > Missing audio support. I sent patches for this today. I hope they'll be
> > merged for 3.5.
> > 
> > Missing PCI-Express support; status above.
> > 
> > I hope board-trimslice* can be deleted in 3.7.
> > 
> > Paz00/Toshiba AC100:
> > 
> > Missing rfkill button support. Defining a good binding for this might
> > prove challenging. Marc Dietrich started work on this a while back. I
> > pinged him to see if he intends to continue this work.

I got no response after my last suggestion to add it below the corresponding 
usb controller [1]. It wasn't a clever idea anyway I think. So the best 
solution would be as Olof suggested to add it as a platform_device. See my 
original patch [2]. If this is ok, I can send a rebased version, and hope that 
the DT people accept it.

Some other things regarding board removal also came into my mind. First, is 
the sdhci order problem solved? Maybe I missed it, but it would be nice if we 
could give the internal emmc a device number of zero and the external reader a 
device number one. Currently it is oposite around and AFAIK device tree 
guaranties no special order unless you enforce it somehow.

Another (maybe a bit off-topic) thing that puzzels me is the how to assign the 
clock to the nvec. The device needs the clock (tegra-i2c.2) but there is no 
sane way to get it. I was thinking to add an device name alias (nvec = tegra-
i2c.2) to the board file so I can use clk_get(&pdev->dev, NULL) instead of 
clk_get_sys which seems to be unwanted. Is it possible to add a "clock" 
property to it?

Otherwise I'm fine with board file removal.

Marc

[1] http://permalink.gmane.org/gmane.linux.ports.tegra/3456
[2] http://permalink.gmane.org/gmane.linux.ports.tegra/3415


> > 
> > This is probably the long-pole for completely removing board files,
> > unless we ignore the rfkill feature and delete the board files anyway.
> 
> if this is the only thing holding it up sunsetting all non-DT boards
> on tegra then I suggest just adding a one-time runtime test that adds
> a platform device on that device tree platform. As long as there
> aren't more of them creeping in over time that should be OK.

Re: Tegra board file deprecation schedule

[Russell King - ARM Linux]

On Sat, Apr 28, 2012 at 06:09:32PM +0200, Marc Dietrich wrote:
> Another (maybe a bit off-topic) thing that puzzels me is the how to assign
> the clock to the nvec.

What's the nvec?

> The device needs the clock (tegra-i2c.2) but there is no sane way to get
> it. I was thinking to add an device name alias (nvec = tegra-i2c.2) to
> the board file so I can use clk_get(&pdev->dev, NULL) instead of 
> clk_get_sys which seems to be unwanted.

clk_get() is preferred in drivers which have struct device's to get them.
And if you know the device name, then I see no problem with the aliasing
approach.

Tegra board file deprecation schedule

[Russell King - ARM Linux]

On Sat, Apr 28, 2012 at 06:09:32PM +0200, Marc Dietrich wrote:
> Another (maybe a bit off-topic) thing that puzzels me is the how to assign
> the clock to the nvec.

What's the nvec?

> The device needs the clock (tegra-i2c.2) but there is no sane way to get
> it. I was thinking to add an device name alias (nvec = tegra-i2c.2) to
> the board file so I can use clk_get(&pdev->dev, NULL) instead of 
> clk_get_sys which seems to be unwanted.

clk_get() is preferred in drivers which have struct device's to get them.
And if you know the device name, then I see no problem with the aliasing
approach.

Re: Tegra board file deprecation schedule

[Marc Dietrich]

On Saturday 28 April 2012 22:34:56 Russell King - ARM Linux wrote:
> On Sat, Apr 28, 2012 at 06:09:32PM +0200, Marc Dietrich wrote:
> > Another (maybe a bit off-topic) thing that puzzels me is the how to assign
> > the clock to the nvec.
> 
> What's the nvec?

it is the embedded controller used on many first gen tegra2 boards 
(drivers/staging/nvec). Do you remember commit 55dc6ee7 ?

> > The device needs the clock (tegra-i2c.2) but there is no sane way to get
> > it. I was thinking to add an device name alias (nvec = tegra-i2c.2) to
> > the board file so I can use clk_get(&pdev->dev, NULL) instead of
> > clk_get_sys which seems to be unwanted.
> 
> clk_get() is preferred in drivers which have struct device's to get them.
> And if you know the device name, then I see no problem with the aliasing
> approach.

I'm just looking for a way to use clk_get if two devices, tegra-i2c and nvec 
(or tegra-i2c-slave in the future) share the same clock. 

Marc

Tegra board file deprecation schedule

[Marc Dietrich]

On Saturday 28 April 2012 22:34:56 Russell King - ARM Linux wrote:
> On Sat, Apr 28, 2012 at 06:09:32PM +0200, Marc Dietrich wrote:
> > Another (maybe a bit off-topic) thing that puzzels me is the how to assign
> > the clock to the nvec.
> 
> What's the nvec?

it is the embedded controller used on many first gen tegra2 boards 
(drivers/staging/nvec). Do you remember commit 55dc6ee7 ?

> > The device needs the clock (tegra-i2c.2) but there is no sane way to get
> > it. I was thinking to add an device name alias (nvec = tegra-i2c.2) to
> > the board file so I can use clk_get(&pdev->dev, NULL) instead of
> > clk_get_sys which seems to be unwanted.
> 
> clk_get() is preferred in drivers which have struct device's to get them.
> And if you know the device name, then I see no problem with the aliasing
> approach.

I'm just looking for a way to use clk_get if two devices, tegra-i2c and nvec 
(or tegra-i2c-slave in the future) share the same clock. 

Marc

Re: Tegra board file deprecation schedule

[Russell King - ARM Linux]

On Sun, Apr 29, 2012 at 08:11:56PM +0200, Marc Dietrich wrote:
> On Saturday 28 April 2012 22:34:56 Russell King - ARM Linux wrote:
> > clk_get() is preferred in drivers which have struct device's to get them.
> > And if you know the device name, then I see no problem with the aliasing
> > approach.
> 
> I'm just looking for a way to use clk_get if two devices, tegra-i2c and nvec 
> (or tegra-i2c-slave in the future) share the same clock. 

Easy if you know the device names for each.  You just have two clk_lookup
entries which point at the exact same struct clk, one for each device.

Tegra board file deprecation schedule

[Russell King - ARM Linux]

On Sun, Apr 29, 2012 at 08:11:56PM +0200, Marc Dietrich wrote:
> On Saturday 28 April 2012 22:34:56 Russell King - ARM Linux wrote:
> > clk_get() is preferred in drivers which have struct device's to get them.
> > And if you know the device name, then I see no problem with the aliasing
> > approach.
> 
> I'm just looking for a way to use clk_get if two devices, tegra-i2c and nvec 
> (or tegra-i2c-slave in the future) share the same clock. 

Easy if you know the device names for each.  You just have two clk_lookup
entries which point at the exact same struct clk, one for each device.

Re: Tegra board file deprecation schedule

[Stephen Warren]

On 04/29/2012 12:11 PM, Marc Dietrich wrote:
> On Saturday 28 April 2012 22:34:56 Russell King - ARM Linux wrote:
>> On Sat, Apr 28, 2012 at 06:09:32PM +0200, Marc Dietrich wrote:
>>> Another (maybe a bit off-topic) thing that puzzels me is the how to assign
>>> the clock to the nvec.
>>
>> What's the nvec?
> 
> it is the embedded controller used on many first gen tegra2 boards 
> (drivers/staging/nvec). Do you remember commit 55dc6ee7 ?
> 
>>> The device needs the clock (tegra-i2c.2) but there is no sane way to get
>>> it. I was thinking to add an device name alias (nvec = tegra-i2c.2) to
>>> the board file so I can use clk_get(&pdev->dev, NULL) instead of
>>> clk_get_sys which seems to be unwanted.
>>
>> clk_get() is preferred in drivers which have struct device's to get them.
>> And if you know the device name, then I see no problem with the aliasing
>> approach.
> 
> I'm just looking for a way to use clk_get if two devices, tegra-i2c and nvec 
> (or tegra-i2c-slave in the future) share the same clock. 

Oh, you mean the I2C controller clock.

The correct approach here is to remove all the I2C logic from the NVEC
driver and add I2C slave support to the real I2C driver. Then, NVEC
becomes just a protocol driver for the slave transactions. Then, there
is no clock to deal with.

Tegra board file deprecation schedule

[Stephen Warren]

On 04/29/2012 12:11 PM, Marc Dietrich wrote:
> On Saturday 28 April 2012 22:34:56 Russell King - ARM Linux wrote:
>> On Sat, Apr 28, 2012 at 06:09:32PM +0200, Marc Dietrich wrote:
>>> Another (maybe a bit off-topic) thing that puzzels me is the how to assign
>>> the clock to the nvec.
>>
>> What's the nvec?
> 
> it is the embedded controller used on many first gen tegra2 boards 
> (drivers/staging/nvec). Do you remember commit 55dc6ee7 ?
> 
>>> The device needs the clock (tegra-i2c.2) but there is no sane way to get
>>> it. I was thinking to add an device name alias (nvec = tegra-i2c.2) to
>>> the board file so I can use clk_get(&pdev->dev, NULL) instead of
>>> clk_get_sys which seems to be unwanted.
>>
>> clk_get() is preferred in drivers which have struct device's to get them.
>> And if you know the device name, then I see no problem with the aliasing
>> approach.
> 
> I'm just looking for a way to use clk_get if two devices, tegra-i2c and nvec 
> (or tegra-i2c-slave in the future) share the same clock. 

Oh, you mean the I2C controller clock.

The correct approach here is to remove all the I2C logic from the NVEC
driver and add I2C slave support to the real I2C driver. Then, NVEC
becomes just a protocol driver for the slave transactions. Then, there
is no clock to deal with.

Re: Tegra board file deprecation schedule

[Marc Dietrich]

Am Sonntag, 29. April 2012, 13:16:38 schrieb Stephen Warren:
> On 04/29/2012 12:11 PM, Marc Dietrich wrote:
> > On Saturday 28 April 2012 22:34:56 Russell King - ARM Linux wrote:
> >> On Sat, Apr 28, 2012 at 06:09:32PM +0200, Marc Dietrich wrote:
> >>> Another (maybe a bit off-topic) thing that puzzels me is the how to
> >>> assign
> >>> the clock to the nvec.
> >> 
> >> What's the nvec?
> > 
> > it is the embedded controller used on many first gen tegra2 boards
> > (drivers/staging/nvec). Do you remember commit 55dc6ee7 ?
> > 
> >>> The device needs the clock (tegra-i2c.2) but there is no sane way to get
> >>> it. I was thinking to add an device name alias (nvec = tegra-i2c.2) to
> >>> the board file so I can use clk_get(&pdev->dev, NULL) instead of
> >>> clk_get_sys which seems to be unwanted.
> >> 
> >> clk_get() is preferred in drivers which have struct device's to get them.
> >> And if you know the device name, then I see no problem with the aliasing
> >> approach.
> > 
> > I'm just looking for a way to use clk_get if two devices, tegra-i2c and
> > nvec (or tegra-i2c-slave in the future) share the same clock.
> 
> Oh, you mean the I2C controller clock.
> 
> The correct approach here is to remove all the I2C logic from the NVEC
> driver and add I2C slave support to the real I2C driver. Then, NVEC
> becomes just a protocol driver for the slave transactions. Then, there
> is no clock to deal with.

you are absolutely right, but there is no i2c slave controller driver in 
mainline yet and I don't want to submit the one nvidia already wrote [1]. 
Maybe you can ask around if someone is willing to do this.

Anyway, removal of the board files will not make it worser than it is already 
so this is not a show stopper.

Marc


[1] http://nv-
tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=blob;f=drivers/i2c/busses/i2c-
slave-tegra.c;hb=linux-tegra-nv-3.1

Tegra board file deprecation schedule

[Marc Dietrich]

Am Sonntag, 29. April 2012, 13:16:38 schrieb Stephen Warren:
> On 04/29/2012 12:11 PM, Marc Dietrich wrote:
> > On Saturday 28 April 2012 22:34:56 Russell King - ARM Linux wrote:
> >> On Sat, Apr 28, 2012 at 06:09:32PM +0200, Marc Dietrich wrote:
> >>> Another (maybe a bit off-topic) thing that puzzels me is the how to
> >>> assign
> >>> the clock to the nvec.
> >> 
> >> What's the nvec?
> > 
> > it is the embedded controller used on many first gen tegra2 boards
> > (drivers/staging/nvec). Do you remember commit 55dc6ee7 ?
> > 
> >>> The device needs the clock (tegra-i2c.2) but there is no sane way to get
> >>> it. I was thinking to add an device name alias (nvec = tegra-i2c.2) to
> >>> the board file so I can use clk_get(&pdev->dev, NULL) instead of
> >>> clk_get_sys which seems to be unwanted.
> >> 
> >> clk_get() is preferred in drivers which have struct device's to get them.
> >> And if you know the device name, then I see no problem with the aliasing
> >> approach.
> > 
> > I'm just looking for a way to use clk_get if two devices, tegra-i2c and
> > nvec (or tegra-i2c-slave in the future) share the same clock.
> 
> Oh, you mean the I2C controller clock.
> 
> The correct approach here is to remove all the I2C logic from the NVEC
> driver and add I2C slave support to the real I2C driver. Then, NVEC
> becomes just a protocol driver for the slave transactions. Then, there
> is no clock to deal with.

you are absolutely right, but there is no i2c slave controller driver in 
mainline yet and I don't want to submit the one nvidia already wrote [1]. 
Maybe you can ask around if someone is willing to do this.

Anyway, removal of the board files will not make it worser than it is already 
so this is not a show stopper.

Marc


[1] http://nv-
tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=blob;f=drivers/i2c/busses/i2c-
slave-tegra.c;hb=linux-tegra-nv-3.1

Re: Tegra board file deprecation schedule

[Stephen Warren]

On 04/30/2012 02:58 AM, Marc Dietrich wrote:
> Am Sonntag, 29. April 2012, 13:16:38 schrieb Stephen Warren:
...
>> The correct approach here is to remove all the I2C logic from the NVEC
>> driver and add I2C slave support to the real I2C driver. Then, NVEC
>> becomes just a protocol driver for the slave transactions. Then, there
>> is no clock to deal with.
> 
> you are absolutely right, but there is no i2c slave controller driver in 
> mainline yet and I don't want to submit the one nvidia already wrote [1]. 
> Maybe you can ask around if someone is willing to do this.

Someone has been assigned to work on this, but other priorities are in
the way. Unfortunately, I don't have any realistic ETA I can give right now.

Tegra board file deprecation schedule

[Stephen Warren]

On 04/30/2012 02:58 AM, Marc Dietrich wrote:
> Am Sonntag, 29. April 2012, 13:16:38 schrieb Stephen Warren:
...
>> The correct approach here is to remove all the I2C logic from the NVEC
>> driver and add I2C slave support to the real I2C driver. Then, NVEC
>> becomes just a protocol driver for the slave transactions. Then, there
>> is no clock to deal with.
> 
> you are absolutely right, but there is no i2c slave controller driver in 
> mainline yet and I don't want to submit the one nvidia already wrote [1]. 
> Maybe you can ask around if someone is willing to do this.

Someone has been assigned to work on this, but other priorities are in
the way. Unfortunately, I don't have any realistic ETA I can give right now.

Re: Tegra board file deprecation schedule

[Marc Dietrich]

On Monday 30 April 2012 09:58:02 Stephen Warren wrote:
> On 04/30/2012 02:58 AM, Marc Dietrich wrote:
> > Am Sonntag, 29. April 2012, 13:16:38 schrieb Stephen Warren:
> ...
> 
> >> The correct approach here is to remove all the I2C logic from the NVEC
> >> driver and add I2C slave support to the real I2C driver. Then, NVEC
> >> becomes just a protocol driver for the slave transactions. Then, there
> >> is no clock to deal with.
> > 
> > you are absolutely right, but there is no i2c slave controller driver in
> > mainline yet and I don't want to submit the one nvidia already wrote [1].
> > Maybe you can ask around if someone is willing to do this.
> 
> Someone has been assigned to work on this, but other priorities are in
> the way. Unfortunately, I don't have any realistic ETA I can give right now.

oh, that's nice. The nvec driver is also far from perfect, so we have some 
more time to cleanup the rest.

Marc

Tegra board file deprecation schedule

[Marc Dietrich]

On Monday 30 April 2012 09:58:02 Stephen Warren wrote:
> On 04/30/2012 02:58 AM, Marc Dietrich wrote:
> > Am Sonntag, 29. April 2012, 13:16:38 schrieb Stephen Warren:
> ...
> 
> >> The correct approach here is to remove all the I2C logic from the NVEC
> >> driver and add I2C slave support to the real I2C driver. Then, NVEC
> >> becomes just a protocol driver for the slave transactions. Then, there
> >> is no clock to deal with.
> > 
> > you are absolutely right, but there is no i2c slave controller driver in
> > mainline yet and I don't want to submit the one nvidia already wrote [1].
> > Maybe you can ask around if someone is willing to do this.
> 
> Someone has been assigned to work on this, but other priorities are in
> the way. Unfortunately, I don't have any realistic ETA I can give right now.

oh, that's nice. The nvec driver is also far from perfect, so we have some 
more time to cleanup the rest.

Marc

Re: Tegra board file deprecation schedule

[Stephen Warren]

On 04/28/2012 10:09 AM, Marc Dietrich wrote:
...
> Some other things regarding board removal also came into my mind. First, is 
> the sdhci order problem solved? Maybe I missed it, but it would be nice if we 
> could give the internal emmc a device number of zero and the external reader a 
> device number one. Currently it is oposite around and AFAIK device tree 
> guaranties no special order unless you enforce it somehow.

I think we shouldn't consider there to be an SDHCI order problem.
Relying on block devices to appear with a specific name is probably
something we shouldn't do. The fact it happened with SDHCI is pretty
unique; it doesn't for USB-attached devices, removable SDHCI devices, etc.

Instead, you can use partition or filesystem UUIDs to name devices. I
boot with root=PARTUUID=xxxx these days, and hence never have to adjust
my command-line depending on the SDHCI probe ordering differences, and
it's work just fine for USB or other storage too.

Tegra board file deprecation schedule

[Stephen Warren]

On 04/28/2012 10:09 AM, Marc Dietrich wrote:
...
> Some other things regarding board removal also came into my mind. First, is 
> the sdhci order problem solved? Maybe I missed it, but it would be nice if we 
> could give the internal emmc a device number of zero and the external reader a 
> device number one. Currently it is oposite around and AFAIK device tree 
> guaranties no special order unless you enforce it somehow.

I think we shouldn't consider there to be an SDHCI order problem.
Relying on block devices to appear with a specific name is probably
something we shouldn't do. The fact it happened with SDHCI is pretty
unique; it doesn't for USB-attached devices, removable SDHCI devices, etc.

Instead, you can use partition or filesystem UUIDs to name devices. I
boot with root=PARTUUID=xxxx these days, and hence never have to adjust
my command-line depending on the SDHCI probe ordering differences, and
it's work just fine for USB or other storage too.

Re: Re: Tegra board file deprecation schedule

[Marc Dietrich]

Am Sonntag, 29. April 2012, 13:21:23 schrieb Stephen Warren:
> On 04/28/2012 10:09 AM, Marc Dietrich wrote:
> ...
> 
> > Some other things regarding board removal also came into my mind. First,
> > is
> > the sdhci order problem solved? Maybe I missed it, but it would be nice if
> > we could give the internal emmc a device number of zero and the external
> > reader a device number one. Currently it is oposite around and AFAIK
> > device tree guaranties no special order unless you enforce it somehow.
> 
> I think we shouldn't consider there to be an SDHCI order problem.
> Relying on block devices to appear with a specific name is probably
> something we shouldn't do. The fact it happened with SDHCI is pretty
> unique; it doesn't for USB-attached devices, removable SDHCI devices, etc.
> 
> Instead, you can use partition or filesystem UUIDs to name devices. I
> boot with root=PARTUUID=xxxx these days, and hence never have to adjust
> my command-line depending on the SDHCI probe ordering differences, and
> it's work just fine for USB or other storage too.

Arrr, you are right again. I tend to ignore this unhandy UUID thing, but all 
current distros use it. So this not not an issue. Sorry for the noice.

Marc

Tegra board file deprecation schedule

[Marc Dietrich]

Am Sonntag, 29. April 2012, 13:21:23 schrieb Stephen Warren:
> On 04/28/2012 10:09 AM, Marc Dietrich wrote:
> ...
> 
> > Some other things regarding board removal also came into my mind. First,
> > is
> > the sdhci order problem solved? Maybe I missed it, but it would be nice if
> > we could give the internal emmc a device number of zero and the external
> > reader a device number one. Currently it is oposite around and AFAIK
> > device tree guaranties no special order unless you enforce it somehow.
> 
> I think we shouldn't consider there to be an SDHCI order problem.
> Relying on block devices to appear with a specific name is probably
> something we shouldn't do. The fact it happened with SDHCI is pretty
> unique; it doesn't for USB-attached devices, removable SDHCI devices, etc.
> 
> Instead, you can use partition or filesystem UUIDs to name devices. I
> boot with root=PARTUUID=xxxx these days, and hence never have to adjust
> my command-line depending on the SDHCI probe ordering differences, and
> it's work just fine for USB or other storage too.

Arrr, you are right again. I tend to ignore this unhandy UUID thing, but all 
current distros use it. So this not not an issue. Sorry for the noice.

Marc

Re: Tegra board file deprecation schedule

[Lucas Stach]

Am Freitag, den 27.04.2012, 15:24 -0600 schrieb Stephen Warren:
> Eventually, Tegra support will become device tree only in the mainline
> kernel; arch/arm/mach-tegra/board* will be deleted.
> 
> I propose the following policy towards this goal: I'd like to maintain
> the board files until the relevant device tree file has the same level
> of functionality. Once that is achieved, and a Linus kernel is release
> with full support for the board via device tree, the board files can be
> deleted from the next kernel release.
> 
> Does anyone have any issues with this?

Do we have any way to describe the clocks in the device tree? I'm
planning to add support for the Toradex Colibri T20 processor module,
which uses a 13MHz external OSC, so the generic clock init in the
current dt code definitely won't work for this board.

Thanks,
Lucas

Tegra board file deprecation schedule

[Lucas Stach]

Am Freitag, den 27.04.2012, 15:24 -0600 schrieb Stephen Warren:
> Eventually, Tegra support will become device tree only in the mainline
> kernel; arch/arm/mach-tegra/board* will be deleted.
> 
> I propose the following policy towards this goal: I'd like to maintain
> the board files until the relevant device tree file has the same level
> of functionality. Once that is achieved, and a Linus kernel is release
> with full support for the board via device tree, the board files can be
> deleted from the next kernel release.
> 
> Does anyone have any issues with this?

Do we have any way to describe the clocks in the device tree? I'm
planning to add support for the Toradex Colibri T20 processor module,
which uses a 13MHz external OSC, so the generic clock init in the
current dt code definitely won't work for this board.

Thanks,
Lucas

Re: Tegra board file deprecation schedule

[Stephen Warren]

On 04/28/2012 03:26 PM, Lucas Stach wrote:
> Am Freitag, den 27.04.2012, 15:24 -0600 schrieb Stephen Warren:
>> Eventually, Tegra support will become device tree only in the mainline
>> kernel; arch/arm/mach-tegra/board* will be deleted.
>>
>> I propose the following policy towards this goal: I'd like to maintain
>> the board files until the relevant device tree file has the same level
>> of functionality. Once that is achieved, and a Linus kernel is release
>> with full support for the board via device tree, the board files can be
>> deleted from the next kernel release.
>>
>> Does anyone have any issues with this?
> 
> Do we have any way to describe the clocks in the device tree?

Not at present, although supporting that will probably be part of
Tegra's support of the common clock API and DT bindings.

> I'm
> planning to add support for the Toradex Colibri T20 processor module,
> which uses a 13MHz external OSC, so the generic clock init in the
> current dt code definitely won't work for this board.

I'm not actually sure that's true. I believe we measure the OSC
frequency during boot, and all the clock driver PLL tables have (or
should have) entries for the various supported crystal frequencies. I
wouldn't be too surprised if it all just worked, or could easily be
fixed to.

(I wouldn't consider this to be related to board file deprecation, since
there are currently no board files to be deprecated that rely on such a
feature anyway)

Tegra board file deprecation schedule

[Stephen Warren]

On 04/28/2012 03:26 PM, Lucas Stach wrote:
> Am Freitag, den 27.04.2012, 15:24 -0600 schrieb Stephen Warren:
>> Eventually, Tegra support will become device tree only in the mainline
>> kernel; arch/arm/mach-tegra/board* will be deleted.
>>
>> I propose the following policy towards this goal: I'd like to maintain
>> the board files until the relevant device tree file has the same level
>> of functionality. Once that is achieved, and a Linus kernel is release
>> with full support for the board via device tree, the board files can be
>> deleted from the next kernel release.
>>
>> Does anyone have any issues with this?
> 
> Do we have any way to describe the clocks in the device tree?

Not at present, although supporting that will probably be part of
Tegra's support of the common clock API and DT bindings.

> I'm
> planning to add support for the Toradex Colibri T20 processor module,
> which uses a 13MHz external OSC, so the generic clock init in the
> current dt code definitely won't work for this board.

I'm not actually sure that's true. I believe we measure the OSC
frequency during boot, and all the clock driver PLL tables have (or
should have) entries for the various supported crystal frequencies. I
wouldn't be too surprised if it all just worked, or could easily be
fixed to.

(I wouldn't consider this to be related to board file deprecation, since
there are currently no board files to be deprecated that rely on such a
feature anyway)