Hi,
On Tue, Sep 23, 2014 at 07:37:25PM +0200, Arnd Bergmann wrote:
> On Tuesday 23 September 2014 11:55:15 Felipe Balbi wrote:
> > On Tue, Sep 23, 2014 at 06:44:40PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 23 September 2014 15:36:45 Antoine Tenart wrote:
> > > > On Tue, Sep 23, 2014 at 12:39:04PM +0200, Arnd Bergmann wrote:
> > > > > On Tuesday 23 September 2014 12:28:03 Antoine Tenart wrote:
> > > > > > + if (dev->of_node) {
> > > > > > + ret = ci_hdrc_usb2_dt_probe(dev, ci_pdata);
> > > > > > + if (ret)
> > > > > > + goto clk_err;
> > > > > > + } else {
> > > > > > + ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> > > > > > + if (ret)
> > > > > > + goto clk_err;
> > > > > > + }
> > > > > >
> > > > >
> > > > > Why do you care about the non-DT case here? I think it would be nicer to
> > > > > open-code the ci_hdrc_usb2_dt_probe() function in here and remove
> > > > > the dma_set_mask_and_coherent(), which should not even be necessary for
> > > > > the case where you have a hardwired platform device.
> > > > >
> > > >
> > > > I thought we agreed to call dma_set_mask_and_coherent():
> > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/273335.html
> > > >
> > > > I do not have a strong opinion on this as I only use the dt case for my
> > > > usage.
> > >
> > > The question is more about who actually wants the non-DT case.
> > >
> > > Since this is a new driver, I suspect that the answer is "nobody",
> > > as the existing board files are all for legacy platforms that we
> > > are not going to adapt for this driver.
> >
> > wait a minute... will the legacy platforms be adapted to DT and, thus,
> > to this driver in the future ? I really don't want to keep several
> > copies of chipidea driver just because there are still some legacy
> > platforms still using them. I have said in the past and will say again,
> > everybody should move to the generic chipidea driver at the earliest
> > opportunity so we avoid duplication of work.
> >
>
> Sorry, my mistake. The intention that this new driver is meant to
> replace the existing ones wasn't clear to me from the changelog, and
> if I'd been involved in the discussion before, then I've forgotten
> about it.
>
> It absolutely makes sense to migrate to a common driver, and in that
> case we should keep the platform_data handling and
> dma_set_mask_and_coherent() call in there, so we can do the two
> conversions (migrating from platform specific frontends to the generic
> one, and migrating from platform_data to DT) on independent schedules.
makes sense to me.
> Eventually I'd like all of the existing users of the platform_data
> path to move to DT, but that should not hold up the other cleanup if
> it takes longer.
yeah, certainly.
> There is however still my point that we shouldn't have an extra
> platform device that is not attached to the device node. I think the
> generic driver should just be part of the common code, without an
> extra framework. Something like the (entirely untested) patch below.
yeah, that's what I did on dwc3 at least. We support platform_data and
DT on the core driver. As for glue layers, we have ST, Qcom, PCI, OMAP,
Exynos and Keystone.
The only difference is that core dwc3 still doesn't know about clocks,
but that's not an issue right now because we're not yet supporting
pm_runtime.
--
balbi
Attachment:
signature.asc
Description: Digital signature
