Messages in this thread | | | From | David Brownell <> | Subject | Re: [spi-devel-general] [RESEND][PATCH] SPI: xilinx_spi: Added platform driver and support for DS570 | Date | Thu, 2 Jul 2009 18:09:01 -0700 |
| |
On Wednesday 24 June 2009, Richard Röjfors wrote: > On 09-06-23 21.37, David Brownell wrote: > > On Monday 15 June 2009, Richard Röjfors wrote: > >> This patch splits xilinx_spi into three parts, an OF and a platform > >> driver and generic part. > >> > >> The generic part now also works on X86 and also supports the Xilinx > >> SPI IP DS570 > > > > Your Kconfig still mentions only DS464. > > Correct, will update.
Just checking -- you didn't send an update yet, right?
> >> + See the "OPB Serial Peripheral Interface (SPI) (v1.00e)" > >> + Product Specification document (DS464) for hardware details. > >> + > >> +config SPI_XILINX_PLTFM > >> + tristate "Xilinx SPI controller platform device" > >> + depends on SPI_XILINX > > > > This should go first in the Kconfig, so that you don't goof up > > the dependency display ... the OF bits depend on it. > > The OF parts only depend on SPI_XILINX, not SPI_XILINX_PLTFM. But > I can change the order anyway(?)
Maybe I misread something. Make sure the Kconfig doesn't goof.
> >> + /* devices to add to the bus when the host is up */ > >> + struct spi_board_info *devices; > >> + u8 num_devices; > > > > This is duplicating functionality in the SPI core code. > > That's not really the way to fly. > > I have discussed the same problem in the I2C list. > > We have a PCIe device which is a MFD (multifunction device). > > Several MFD devices could be connected to a standard PC -> > we don't know the bus numbers in advance, and there could be > several PCIe devices connected. Which mean the we can not use > spi_register_board_info.
You could, actually, given metadata about those devices. That's one of the things ACPI does -- in a way that many of us find ugly! -- and the "device tree" some PPCs use.
> We can not call spi_add_device from the MFD because when it's > probed the drivers for the SPI bus might not be available.
And you can't call spi_register_board_info() there since the init section is gone.
> So the solution in the I2C case was to add this into the driver > and if this tend to be a generic problem some generic solution might > be implemented. > > So I would like to have the same thing in here.
What I've done in such cases is make sure the bus adapter driver (in this case, for the spi_master) can issue some callback to code which makes spi_add_device(), or similar, calls.
But if your initialization doesn't have that sort of clean structure, it's probably kind of awkward to add it just now... :(
- Dave
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |