From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752313Ab2FMHBH (ORCPT ); Wed, 13 Jun 2012 03:01:07 -0400 Received: from mail-ey0-f174.google.com ([209.85.215.174]:56459 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752000Ab2FMHBF (ORCPT ); Wed, 13 Jun 2012 03:01:05 -0400 Message-ID: <4FD83AAD.2010701@linaro.org> Date: Wed, 13 Jun 2012 08:01:01 +0100 From: Lee Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Linus Walleij CC: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linus.walleij@stericsson.com, arnd@arndb.de, grant.likely@secretlab.ca, linux-i2c@vger.kernel.org Subject: Re: [PATCH 09/14] i2c: Add Device Tree support to the Nomadik I2C driver References: <1339428307-3850-1-git-send-email-lee.jones@linaro.org> <1339428307-3850-10-git-send-email-lee.jones@linaro.org> <4FD6F0E8.5040606@linaro.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/06/12 06:40, Linus Walleij wrote: > On Tue, Jun 12, 2012 at 9:34 AM, Lee Jones wrote: >> On 11/06/12 21:37, Linus Walleij wrote: >>> >>> So why don't we create proper device tree bindings for the above platform >>> data? >>> (...) >>> This looks to me like a way to push the burden of doing the real >>> device tree binding for the above to the next user. >>> (Which will likely be me, so therefore I care a bit ...) >> >> >> On the contrary. This will avoid any added Device Tree complexity and ensure >> that no extra vendor specific bindings are required. When a new user wishes >> to use the driver, all they (you) have to do is create a new struct with the >> platform specific information and add the entry to nmk_gpio_match[], >> simples. >> >> I've even added the logic to extract any information you provide via >> nmk_gpio_match[] for use as platform data. This keeps it both out of >> platform code and the Device Tree binary. Everyone's a winner. :) > > No. You assume that the platform data is a chip-specific property, > and that it will be the same for all busses on the chip. But it > isn't. > > The above platform data is *board specific*, it depends on > what devices have been connected to each bus. > > For example the max frequency: this depends on the maximum > frequency any of the devices connected to one very bus > can support. > > The other platforms have put this frequency into their device > trees for a reason, and this is it. > > So for the four different i2c busses there may need to be > four different platform data sets. How are you going to > distinguish between the four buses? > > This is thus broken and needs to have proper bindings. Board specific is fine, as the data is protected by a board specific property. Do you mean that the properties are *bus specific*? In which case I see your point and will apply the correct bindings. -- Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lee Jones Subject: Re: [PATCH 09/14] i2c: Add Device Tree support to the Nomadik I2C driver Date: Wed, 13 Jun 2012 08:01:01 +0100 Message-ID: <4FD83AAD.2010701@linaro.org> References: <1339428307-3850-1-git-send-email-lee.jones@linaro.org> <1339428307-3850-10-git-send-email-lee.jones@linaro.org> <4FD6F0E8.5040606@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-i2c-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Linus Walleij Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org, arnd-r2nGTMty4D4@public.gmane.org, grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org, linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-i2c@vger.kernel.org On 13/06/12 06:40, Linus Walleij wrote: > On Tue, Jun 12, 2012 at 9:34 AM, Lee Jones wro= te: >> On 11/06/12 21:37, Linus Walleij wrote: >>> >>> So why don't we create proper device tree bindings for the above pl= atform >>> data? >>> (...) >>> This looks to me like a way to push the burden of doing the real >>> device tree binding for the above to the next user. >>> (Which will likely be me, so therefore I care a bit ...) >> >> >> On the contrary. This will avoid any added Device Tree complexity an= d ensure >> that no extra vendor specific bindings are required. When a new user= wishes >> to use the driver, all they (you) have to do is create a new struct = with the >> platform specific information and add the entry to nmk_gpio_match[], >> simples. >> >> I've even added the logic to extract any information you provide via >> nmk_gpio_match[] for use as platform data. This keeps it both out of >> platform code and the Device Tree binary. Everyone's a winner. :) > > No. You assume that the platform data is a chip-specific property, > and that it will be the same for all busses on the chip. But it > isn't. > > The above platform data is *board specific*, it depends on > what devices have been connected to each bus. > > For example the max frequency: this depends on the maximum > frequency any of the devices connected to one very bus > can support. > > The other platforms have put this frequency into their device > trees for a reason, and this is it. > > So for the four different i2c busses there may need to be > four different platform data sets. How are you going to > distinguish between the four buses? > > This is thus broken and needs to have proper bindings. Board specific is fine, as the data is protected by a board specific=20 property. Do you mean that the properties are *bus specific*? In which=20 case I see your point and will apply the correct bindings. --=20 Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org =E2=94=82 Open source software for ARM SoCs =46ollow Linaro: Facebook | Twitter | Blog From mboxrd@z Thu Jan 1 00:00:00 1970 From: lee.jones@linaro.org (Lee Jones) Date: Wed, 13 Jun 2012 08:01:01 +0100 Subject: [PATCH 09/14] i2c: Add Device Tree support to the Nomadik I2C driver In-Reply-To: References: <1339428307-3850-1-git-send-email-lee.jones@linaro.org> <1339428307-3850-10-git-send-email-lee.jones@linaro.org> <4FD6F0E8.5040606@linaro.org> Message-ID: <4FD83AAD.2010701@linaro.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 13/06/12 06:40, Linus Walleij wrote: > On Tue, Jun 12, 2012 at 9:34 AM, Lee Jones wrote: >> On 11/06/12 21:37, Linus Walleij wrote: >>> >>> So why don't we create proper device tree bindings for the above platform >>> data? >>> (...) >>> This looks to me like a way to push the burden of doing the real >>> device tree binding for the above to the next user. >>> (Which will likely be me, so therefore I care a bit ...) >> >> >> On the contrary. This will avoid any added Device Tree complexity and ensure >> that no extra vendor specific bindings are required. When a new user wishes >> to use the driver, all they (you) have to do is create a new struct with the >> platform specific information and add the entry to nmk_gpio_match[], >> simples. >> >> I've even added the logic to extract any information you provide via >> nmk_gpio_match[] for use as platform data. This keeps it both out of >> platform code and the Device Tree binary. Everyone's a winner. :) > > No. You assume that the platform data is a chip-specific property, > and that it will be the same for all busses on the chip. But it > isn't. > > The above platform data is *board specific*, it depends on > what devices have been connected to each bus. > > For example the max frequency: this depends on the maximum > frequency any of the devices connected to one very bus > can support. > > The other platforms have put this frequency into their device > trees for a reason, and this is it. > > So for the four different i2c busses there may need to be > four different platform data sets. How are you going to > distinguish between the four buses? > > This is thus broken and needs to have proper bindings. Board specific is fine, as the data is protected by a board specific property. Do you mean that the properties are *bus specific*? In which case I see your point and will apply the correct bindings. -- Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog