----- Original Message -----
> From: "Grant Likely" <[email protected]>
> To: "Masayuki Ohtake" <[email protected]>
> Cc: "Thomas Gleixner" <[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: 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
> <[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.
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)
On Mon, Aug 30, 2010 at 7:45 PM, Masayuki Ohtake
<[email protected]> wrote:
> ----- Original Message -----
>> From: "Grant Likely" <[email protected]>
>> To: "Masayuki Ohtake" <[email protected]>
>> Cc: "Thomas Gleixner" <[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: 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
>> <[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.
>
> How should we register spi_device information ?
> Could you show reference driver ?
Well, to start with, the registration code currently in
spi_pch_device.c is probably pretty much unusable for any platform
other than the development board that you're working on. Every
machine using the topcliff chip will have a different set of spi
devices attached to the bus. So, you'll need a method for having a
different set of registrations depending on the machine.
Traditionally with ARM systems, there is a separate .c file for each
machine (see arch/arm/mach-*/*.c) which registers the expected
devices. In PowerPC the spi devices are described in a device tree
file (arch/powerpc/boot/dts/*) which the kernel will parse and
register the devices it finds. x86 doesn't support either approach
because traditionally the kernel is either able to detect the
hardware, or it can get information from the BIOS (which doesn't work
for embedded x86).
The x86 maintainers want to adopt the device tree approach for
describing devices. Using device tree data in an spi bus driver is
easy. All that is required is to supply the of_node pointer to the
spi bus before registering it. Search for 'of_node' in
drivers/spi/mpc52xx_spi.c for an example. However, device tree
support is not yet available for x86, so there is still some
development that needs to be done.
Regardless, the topcliff spi driver can still be merged into mainline
without the spi_device registration code, and you can keep your
personal copy of spi_pch_device.c for testing while the details about
device tree support for x86 get worked out.
g.