On Sat, Aug 13, 2011 at 11:34:15PM +0200, Arnd Bergmann wrote: > On Saturday 13 August 2011 12:46:45 David Brown wrote: > > > > I'm not sure actually what is best to use here. I'm thinking that the > > 'lite' identifier should perhaps go away. MSM's have two UARTS on > > them, an older "simple" PIO type of UART, and a newer one that can do > > DMA (called the hsuart for high-speed). The hsuart can also be used > > in a non-DMA driver in a mostly compatible way with the old UART. > > > > For non-high-speed applications, the user will probably just want to > > use the non-DMA driver. My question is then: if the device tree > > describes it as > > > > compatible = "qcom,msm-hsuart", "qcom,msm-uart"; > > > > and one driver matches qcom,msm-hsuart and another matches > > qcom,msm-uart, which driver will get used. Ideally, it would use the > > earliest one in the list. > > > > If that's the case, I'll get rid of the -lite suffix and just make the > > non-DMA driver compatible with the plain "qcom,msm-uart". > > I believe that unfortunately the answer is that the first driver that > matches anything will get used. There are two possible ways that I can > see to make it do what you want anyway: > > 1. In the probe function for the slow driver, you return an error > when the device you get passed matches "qcom,msm-hsuart", possibly > dependent on whether the other driver also got built. > > 2. You register one platform driver that handles both names and > gives the device to just one of the two drivers. This would probably > require linking the two drivers into the same module, or having > the non-DMA speed driver just act as a library. How about if I just keep it simple for now. Since there isn't actually a driver for the DMA version, this driver will handle both UART blocks, so I'll just do the plain thing in the DT. In the future, when a DMA-capable driver exists, we can figure out how to determine which driver should be used. At this point, I'm not even sure what the correct answer will be, since a given configuration may want to use non-DMA for one msm-hsuart device, and the DMA driver for another. It's kind of board/use specific, but beyond just describing what the hardware is. I've just sent new patches with this fixed up. David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
