lkml.org 
[lkml]   [2010]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [MeeGo-Dev][PATCH] Topcliff: Update PCH_SPI driver to 2.6.35
    Date
    ----- Original Message ----- 
    > From: "Grant Likely" <grant.likely@secretlab.ca>
    > To: "Masayuki Ohtake" <masa-korg@dsn.okisemi.com>
    > Cc: "Thomas Gleixner" <tglx@linutronix.de>; <meego-dev@meego.com>; "LKML" <linux-kernel@vger.kernel.org>; "David
    Brownell" <dbrownell@users.sourceforge.net>; <qi.wang@intel.com>; <yong.y.wang@intel.com>;
    <andrew.chih.howe.khor@intel.com>; <arjan@linux.intel.com>; <gregkh@suse.de>; "Tomoya MORINAGA"
    <morinaga526@dsn.okisemi.com>; "David Woodhouse" <dwmw2@infradead.org>; "Alan Cox" <alan@lxorguk.ukuu.org.uk>
    > Sent: Tuesday, August 31, 2010 3:23 AM
    > Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_SPI driver to 2.6.35
    >
    >
    > On Mon, Aug 30, 2010 at 1:28 AM, Masayuki Ohtake
    > <masa-korg@dsn.okisemi.com> wrote:
    > > ----- Original Message -----
    > > From: "Grant Likely" <grant.likely@secretlab.ca>
    > > To: "Thomas Gleixner" <tglx@linutronix.de>
    > > Cc: "Masayuki Ohtak" <masa-korg@dsn.okisemi.com>; <meego-dev@meego.com>; "LKML" <linux-kernel@vger.kernel.org>;
    "David
    > > Brownell" <dbrownell@users.sourceforge.net>; <qi.wang@intel.com>; <yong.y.wang@intel.com>;
    > > <andrew.chih.howe.khor@intel.com>; <arjan@linux.intel.com>; <gregkh@suse.de>; "Tomoya MORINAGA"
    > > <morinaga526@dsn.okisemi.com>; "David Woodhouse" <dwmw2@infradead.org>; "Alan Cox" <alan@lxorguk.ukuu.org.uk>
    > > Sent: Saturday, August 28, 2010 4:20 AM
    > > Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_SPI driver to 2.6.35
    > >
    > >
    > >> On Fri, Aug 27, 2010 at 12:53 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
    > >> > B1;2401;0cOn Fri, 27 Aug 2010, Grant Likely wrote:
    > >> >> [cc'ing Thomas Gleixner and David Woodhouse since this driver needs to
    > >> >> get some data about the platform (to know what spi_devices are
    > >> >> present) and I don't know how that is handled for x86 SoCs.]
    > >> >
    > >> > The best way to do all this platform specific configuration is to use
    > >> > device tree. I really don't want to have x86/mach-xyz/board[A-Z]
    > >> > horror, which is unavoidable when we don't get a sensible way to
    > >> > configure the boards.
    > >>
    > >> I knew you were going to say that! :-)
    > >>
    > >> Ohtak-san, for this patch I'd like you to drop the separate driver
    > >> that only registers the spi_devices and just submit the core driver.
    > >
    > > Sorry, I can't follow your discussion by lack of SPI knowledge.
    > > Which the above mean that "spi_register_board_info" moves to our spi_pch or
    > > delete for our driver ?
    >
    > I mean remove drivers/spi/spi_pch_device.c and the related Kconfig
    > bits from this patch.
    > The spi_device registration is a separate task
    > which should be submitted in a separate patch, and would be better
    > handled in either platform support code or with a device tree.

    How should we register spi_device information ?
    Could you show reference driver ?

    >
    > >> (You can of course keep the spi_device registration in your own tree
    > >> for debug purposes). I'll expect that the device will get
    > >> instantiated using a device tree to determine which spi_devices are
    > >> present. The parsing of spi device tree data will be moving into the
    > >> core spi subsystem code in the next merge window most likely, so it
    > >> can all be handled transparently.
    > >>
    > >> > SFI was meant to provide a lightweight ACPI, but
    > >> > now that device tree is generic and more platforms are using it, I
    > >> > really want to standartize on that and forget SFI.
    > >> >
    > >> > That makes even more sense, as all these AMBA peripherals which are
    > >> > duct-taped to a x86 core can be found in other SoCs with different
    > >> > cores as well.
    > >>
    > >> Indeed. BTW, Ohtak-san, is this spi bus device something brand new,
    > >> or is it derived from an existing spi device?
    > >
    > > Yes, Intel Topcliff is new concept device.
    >
    > As Thomas already commented, what I'm really interested in is whether
    > or not this spi controller is based on an older SPI controller. If it
    > is, then it may be possible to add support for this chip to an
    > existing driver instead of writing a whole new one.
    >



    Thanks, Ohtake(OKISemi)





    \
     
     \ /
      Last update: 2010-08-31 03:47    [W:0.033 / U:0.228 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site