All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Dooks <ben.dooks@codethink.co.uk>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [GIT PULL 00/21] Renesas ARM based SoC Board Updates for v3.15
Date: Thu, 20 Mar 2014 15:25:55 +0000	[thread overview]
Message-ID: <532B0883.9090509@codethink.co.uk> (raw)
In-Reply-To: <201402251704.54970.arnd@arndb.de>

On 25/02/14 17:04, Arnd Bergmann wrote:
> On Tuesday 25 February 2014, Magnus Damm wrote:
>> On Thu, Feb 20, 2014 at 5:23 PM, Olof Johansson <olof@lixom.net> wrote:
>>> On Thu, Feb 06, 2014 at 03:17:08PM +0900, Simon Horman wrote:
>> Thanks for your email. I agree that the number of board file commits
>> is definitely larger than zero so some clarification is in order.
>>
>> As you probably recall, we earlier agreed on not adding any new board
>> files. That part is clear I believe so I will skip that.
>>
>> Regarding the legacy board code, we have quite ok hardware support
>> coverage as it is now, but some devices drivers are of course still
>> under development. This means that in some cases integration is on
>> going or has not happened yet. You may see those kind of changes as
>> significant commits in the pull requests for board support.
>
> [adding Ben Dooks, since he was complaining about this as well]

that's putting it mildly....

> My feeling is that we should adjust the strategy for shmobile. We've
> had good success with the dual strategy of keeping board support
> separate for DT-enabled and ATAGS-only boards in the sense that
> we did not have to coordinate updates for bindings between subsystem
> and architecture git trees, which has always been source for
> problems on other platforms.

Personally, I would be happy with no more platform support at-all.

> However, the price for this seems to be that it's still not possible
> to get a properly working system without a board file, and my feeling
> is that it's taking too long to get there. In particular, we now see
> new drivers getting added (I noticed VIN, which Ben mentioned before)
> that start out with just platform_device support but no DT support.
> This is bad, because it means DT users are always behind.

Agreed, for development purposes my current development tree I
am using on the Lager is showing:

  136 files changed, 13142 insertions(+), 1765 deletions(-)

This includes a specific lager_defconfig and Simon's development
work at the time 3.14-rc3 was out.

>> In the Legacy Lager/Koelsch board code the following devices are
>> supported as platform devices:
>>
>> ETHER, SCIF, DU, I2C, SATA*, USB*, MSIOF*, SDHI*, QSPI*, MMCIF,
>> Audio*, VIN*, Thermal, IRQC, PFC, CMT
>>
>> * Platform device support under development in v3.15-pre
>>
>> In the Multiplatform DT for Lager/Koelsch the following devices have DT support:
>>
>> ETHER, SCIF**, I2C, SATA, MSIOF, SDHI, QSPI, MMCIF, Thermal, IRQC, PFC, CMT**

I've tested Ether, I2C, SHDI and MMCIF.

>> ** Driver DT binding development on-going but integration not finalized
>>
>> In Multiplatform DT for Lager/Koelsch the following devices lack DT bindings:
>>
>> DU (drm/kms)
>> USB (host/function/phy)
>> Audio (alsa-soc + dmac)
>> VIN (v4l2 + camera sensor)
>
> Ok, thanks for the list.

The ALSA is on list and seems to be working with minor patches for
the odd issue we found when testing. I will re-post the DMAC branch
tonight for people to review.

VIN, I've sent patches for but these need to be re-sent with some
updates for soc-camera as well as the video input driver updates.

The USB is currently work in progress, both Sergei and I have sent
patches for the PHY, I have patches for DT for the USB host on list.

I feel this would have been faster if we had not found multiple issues
such as the pm_runtime, and bugs in some of the dt support that seems
to have missed being tested until the above have been attempted.

I hope between Geert, Laurent, Sergei and the people at Renesas we've
made some significant steps forward this release cycle. The issues
with pm_runtime should now be sorted as well as other device-tree
problems with shmobile.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

WARNING: multiple messages have this Message-ID (diff)
From: ben.dooks@codethink.co.uk (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL 00/21] Renesas ARM based SoC Board Updates for v3.15
Date: Thu, 20 Mar 2014 16:25:55 +0100	[thread overview]
Message-ID: <532B0883.9090509@codethink.co.uk> (raw)
In-Reply-To: <201402251704.54970.arnd@arndb.de>

On 25/02/14 17:04, Arnd Bergmann wrote:
> On Tuesday 25 February 2014, Magnus Damm wrote:
>> On Thu, Feb 20, 2014 at 5:23 PM, Olof Johansson <olof@lixom.net> wrote:
>>> On Thu, Feb 06, 2014 at 03:17:08PM +0900, Simon Horman wrote:
>> Thanks for your email. I agree that the number of board file commits
>> is definitely larger than zero so some clarification is in order.
>>
>> As you probably recall, we earlier agreed on not adding any new board
>> files. That part is clear I believe so I will skip that.
>>
>> Regarding the legacy board code, we have quite ok hardware support
>> coverage as it is now, but some devices drivers are of course still
>> under development. This means that in some cases integration is on
>> going or has not happened yet. You may see those kind of changes as
>> significant commits in the pull requests for board support.
>
> [adding Ben Dooks, since he was complaining about this as well]

that's putting it mildly....

> My feeling is that we should adjust the strategy for shmobile. We've
> had good success with the dual strategy of keeping board support
> separate for DT-enabled and ATAGS-only boards in the sense that
> we did not have to coordinate updates for bindings between subsystem
> and architecture git trees, which has always been source for
> problems on other platforms.

Personally, I would be happy with no more platform support at-all.

> However, the price for this seems to be that it's still not possible
> to get a properly working system without a board file, and my feeling
> is that it's taking too long to get there. In particular, we now see
> new drivers getting added (I noticed VIN, which Ben mentioned before)
> that start out with just platform_device support but no DT support.
> This is bad, because it means DT users are always behind.

Agreed, for development purposes my current development tree I
am using on the Lager is showing:

  136 files changed, 13142 insertions(+), 1765 deletions(-)

This includes a specific lager_defconfig and Simon's development
work at the time 3.14-rc3 was out.

>> In the Legacy Lager/Koelsch board code the following devices are
>> supported as platform devices:
>>
>> ETHER, SCIF, DU, I2C, SATA*, USB*, MSIOF*, SDHI*, QSPI*, MMCIF,
>> Audio*, VIN*, Thermal, IRQC, PFC, CMT
>>
>> * Platform device support under development in v3.15-pre
>>
>> In the Multiplatform DT for Lager/Koelsch the following devices have DT support:
>>
>> ETHER, SCIF**, I2C, SATA, MSIOF, SDHI, QSPI, MMCIF, Thermal, IRQC, PFC, CMT**

I've tested Ether, I2C, SHDI and MMCIF.

>> ** Driver DT binding development on-going but integration not finalized
>>
>> In Multiplatform DT for Lager/Koelsch the following devices lack DT bindings:
>>
>> DU (drm/kms)
>> USB (host/function/phy)
>> Audio (alsa-soc + dmac)
>> VIN (v4l2 + camera sensor)
>
> Ok, thanks for the list.

The ALSA is on list and seems to be working with minor patches for
the odd issue we found when testing. I will re-post the DMAC branch
tonight for people to review.

VIN, I've sent patches for but these need to be re-sent with some
updates for soc-camera as well as the video input driver updates.

The USB is currently work in progress, both Sergei and I have sent
patches for the PHY, I have patches for DT for the USB host on list.

I feel this would have been faster if we had not found multiple issues
such as the pm_runtime, and bugs in some of the dt support that seems
to have missed being tested until the above have been attempted.

I hope between Geert, Laurent, Sergei and the people at Renesas we've
made some significant steps forward this release cycle. The issues
with pm_runtime should now be sorted as well as other device-tree
problems with shmobile.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

  parent reply	other threads:[~2014-03-20 15:25 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-06  6:17 [GIT PULL 00/21] Renesas ARM based SoC Board Updates for v3.15 Simon Horman
2014-02-06  6:17 ` Simon Horman
2014-02-06  6:18 ` [PATCH 01/21] ARM: shmobile: Lager: conditionally select CONFIG_MICREL_PHY Simon Horman
2014-02-06  6:18   ` Simon Horman
2014-02-06  6:18 ` [PATCH 02/21] ARM: shmobile: bockw: use SSI DMAEngine for sound Simon Horman
2014-02-06  6:18   ` Simon Horman
2014-02-06  6:18 ` [PATCH 03/21] ARM: shmobile: bockw: use HPBIF " Simon Horman
2014-02-06  6:18   ` Simon Horman
2014-02-06  6:18 ` [PATCH 04/21] ARM: shmobile: bockw: add USB Func DMAEngine support Simon Horman
2014-02-06  6:18   ` Simon Horman
2014-02-06  6:18 ` [PATCH 05/21] ARM: shmobile: koelsch: Conditionally select MICREL_PHY for Multiplatform Simon Horman
2014-02-06  6:18   ` Simon Horman
2014-02-06  6:18 ` [PATCH 06/21] ARM: mach-shmobile: kzm9g: add zboot support Simon Horman
2014-02-06  6:18   ` Simon Horman
2014-02-06  6:18 ` [PATCH 07/21] ARM: shmobile: lager: Add VIN1 SoC camera support Simon Horman
2014-02-06  6:18   ` Simon Horman
2014-02-06  6:19 ` [PATCH 08/21] ARM: shmobile: kzm9d: Use common clock framework Simon Horman
2014-02-06  6:19   ` Simon Horman
2014-02-06  6:19 ` [PATCH 09/21] ARM: shmobile: lager: Make spi_flash_data const Simon Horman
2014-02-06  6:19   ` Simon Horman
2014-02-06  6:19 ` [PATCH 10/21] ARM: shmobile: lager: Add SATA support Simon Horman
2014-02-06  6:19   ` Simon Horman
2014-02-06  6:19 ` [PATCH 11/21] ARM: shmobile: koelsch: Add SATA0 support Simon Horman
2014-02-06  6:19   ` Simon Horman
2014-02-06  6:19 ` [PATCH 12/21] ARM: shmobile: ape6evm: Conditionally select SMSC_PHY Simon Horman
2014-02-06  6:19   ` Simon Horman
2014-02-06  6:19 ` [PATCH 13/21] ARM: shmobile: armadillo800eva: " Simon Horman
2014-02-06  6:19   ` Simon Horman
2014-02-06  6:19 ` [PATCH 14/21] ARM: shmobile: bockw: Sort Kconfig node's selections Simon Horman
2014-02-06  6:19   ` Simon Horman
2014-02-06  6:19 ` [PATCH 15/21] ARM: shmobile: kzm9d: Conditionally select SMSC_PHY Simon Horman
2014-02-06  6:19   ` Simon Horman
2014-02-06  6:19 ` [PATCH 16/21] ARM: shmobile: mackerel: " Simon Horman
2014-02-06  6:19   ` Simon Horman
2014-02-06  6:19 ` [PATCH 17/21] ARM: shmobile: marzen: " Simon Horman
2014-02-06  6:19   ` Simon Horman
2014-02-06  6:19 ` [PATCH 18/21] ARM: shmobile: lager: fix error return code check from clk_get() Simon Horman
2014-02-06  6:19   ` Simon Horman
2014-02-06  6:19 ` [PATCH 19/21] ARM: shmobile: koelsch: " Simon Horman
2014-02-06  6:19   ` Simon Horman
2014-02-06  6:19 ` [PATCH 20/21] ARM: shmobile: lager: Add USBHS support Simon Horman
2014-02-06  6:19   ` Simon Horman
2014-02-06  6:19 ` [PATCH 21/21] ARM: shmobile: Remove Lager USBHS UDC ifdefs Simon Horman
2014-02-06  6:19   ` Simon Horman
2014-02-20  8:23 ` [GIT PULL 00/21] Renesas ARM based SoC Board Updates for v3.15 Olof Johansson
2014-02-20  8:23   ` Olof Johansson
2014-02-25  3:14   ` Magnus Damm
2014-02-25  3:14     ` Magnus Damm
2014-02-25 16:04     ` Arnd Bergmann
2014-02-25 16:04       ` Arnd Bergmann
2014-02-28  4:21       ` Magnus Damm
2014-02-28  4:21         ` Magnus Damm
2014-03-11 21:20         ` Olof Johansson
2014-03-11 21:20           ` Olof Johansson
2014-03-20 15:25       ` Ben Dooks [this message]
2014-03-20 15:25         ` Ben Dooks

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=532B0883.9090509@codethink.co.uk \
    --to=ben.dooks@codethink.co.uk \
    --cc=linux-arm-kernel@lists.infradead.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.