----- Original Message -----
From: "Grant Likely" <[email protected]>
To: "Thomas Gleixner" <[email protected]>
Cc: "Masayuki Ohtak" <[email protected]>; <[email protected]>; "LKML" <[email protected]>; "David
Brownell" <[email protected]>; <[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>; <[email protected]>; "Tomoya MORINAGA"
<[email protected]>; "David Woodhouse" <[email protected]>; "Alan Cox" <[email protected]>
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 <[email protected]> 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 ?
> (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.
Thanks, Ohtake(OKISEMI)
On Mon, 30 Aug 2010, Masayuki Ohtake wrote:
> > 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.
Thats right, but the question was whether the SPI peripheral is a new
IP design or similar to some already supported AMBA SPI peripheral.
Maybe the Intel folks can shed some light on that.
Thanks,
tglx
On Mon, Aug 30, 2010 at 1:28 AM, Masayuki Ohtake
<[email protected]> wrote:
> ----- Original Message -----
> From: "Grant Likely" <[email protected]>
> To: "Thomas Gleixner" <[email protected]>
> Cc: "Masayuki Ohtak" <[email protected]>; <[email protected]>; "LKML" <[email protected]>; "David
> Brownell" <[email protected]>; <[email protected]>; <[email protected]>;
> <[email protected]>; <[email protected]>; <[email protected]>; "Tomoya MORINAGA"
> <[email protected]>; "David Woodhouse" <[email protected]>; "Alan Cox" <[email protected]>
> 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 <[email protected]> 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.
>> (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.
g.