On Mon, 2013-12-09 at 13:34 +0400, Sergei Ianovich wrote: > On Mon, 2013-12-09 at 10:04 +0100, Daniel Mack wrote: > > On 12/09/2013 02:33 AM, Arnd Bergmann wrote: > > > On Sunday 08 December 2013, Sergei Ianovich wrote: > > >> Non-dts implementation supply required DMA channel numbers as > > >> IORESOURCE_DMA. However, there is was no way to get them from > > >> device tree. > > > > > > I just wrote a lengthy reply to this email to explain in what ways > > > you got it wrong, but then I saw that Daniel has already done all > > > the work in the right way in August, so nevermind that. > > > > > > It hasn't made it upstream yet, but see http://list-archives.org/2013/08/07/linux-mtd-lists-infradead-org/patch-00-20-arm-pxa-move-core-and-drivers-to-dmaengine/f/3444199144 > > > for how it's done. Maybe Daniel can comment on the status of his > > > patches. > > > > I recently rebased all my patches on top of 3.13-rc3, and will resend in > > couple of days. > > > > The real problem here is that by reworking the DMA related PXA bits, all > > drivers have to be changed at once, and a gradual transition seems > > impossible. For that, I was asking for help in areas where I don't have > > any hardware to test my patches on, but unfortunately, nobody got back > > to me yet. > > Nice to have Daniel in this conversation. Your patch series is a big and > important work. However, I am not sure I will ever land as is exactly > for this reason. s/I will/it will/ > DMA is a per-physical-device concept, not per-platform. Only the DMA > controller is per-platform. This means we need to rewrite all platform > drivers at once. This is roughly equivalent to adding a new platform > support in one patch, which is not going to work. > > In patch 08/20 in the series above, you change 10% lines of the pxa mmc > driver. If we don't count boilerplate lines, this will amount to over > 50%. In other word, the output is a new driver. s/other word/other words/ > My proposal in to actually add new drivers for each platform device with > DMA and mark new ones EXPERIMENTAL. When they receive adequate testing > we remove the tag and mark the old one OBSOLETE. When we have a new > driver for every device presently supported, we will drop the whole old > series. s/proposal in/proposal is/ > This should be very close to a gradual transition. > > While we are in transition, I propose that we allow 'hackish' support > for device tree in the existing drivers. Platform devices are declared > in dtsi files, so when we move to a new driver we just change the > compatible string there. Actual devices with their one dts file won't > need any change. They will need a dtb recompile, though. This way we can > begin a migration to device tree in pxa immediately. s/their one/their own/ > The patch series does just that. Sorry for noise. -- 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
