lkml.org 
[lkml]   [2017]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the sdhci-omap controller
* Kishon Vijay Abraham I <kishon@ti.com> [170905 01:53]:
> Hi,
>
> On Tuesday 29 August 2017 11:09 PM, Tony Lindgren wrote:
> > * Rob Herring <robh@kernel.org> [170829 10:09]:
> >> On Tue, Aug 29, 2017 at 06:58:23AM -0700, Tony Lindgren wrote:
> >>> * Sebastian Reichel <sebastian.reichel@collabora.co.uk> [170829 04:51]:
> >>>> I would expect the conversion to look like the one done for UART,
> >>>> see CONFIG_SERIAL_OMAP vs CONFIG_SERIAL_8250_OMAP. Both use the
> >>>> same compatible value and you can choose using kernel configuration.
> >>>
> >>> That does not work unfortunately :( We are now stuck in a situation
> >>> where two drivers are attempting to probe with the same compatible
> >>> and we can't enable 8250_OMAP because of the user space breakage
> >>> with the device names. And I'm actuallly thinking we should add a
> >>> new compatible for 8250-omap to be able to start enabling it one
> >>> board at a time.
> >>
> >> Is that the only problem? Presumably, the SD driver doesn't have a
> >> userspace facing issue.
> >
> > No userspace issue with the sdhci-omap. But the sdhci-omap driver
> > still has the issue of trying enable it for everything at once and
> > expect everything to work. The sdhci-omap driver can already be
> > used for boards that don't need power management for example, but
> > will break things for devices running on batteries.
> >
> >>> It's best to enable devices to use the new compatible as things are
> >>> tested rather than hope for some magic "flag day" flip that might
> >>> never happen. Having two days attempting to probe with the same
> >>> binding just won't work.
> >>
> >> Aren't you just picking whether the flag day is in DT or the kernel? I
> >> guess you're assuming one kernel build and it would be switching all
> >> boards at one.
> >
> > Right, this would be risky and would take unnecessarily long
> > to use the new driver on boards that can already use it. While
> > power management won't work yet, I'd expect the sdhci-omap be
> > faster on SoCs that can do ADMA.
> >
> >>> So yeah, I agree with Kishon that we should stick with generic
> >>> and sdhci bindings. And then we can start already using it for
> >>> boards that can use it, then eventually when we're ready, start
> >>> parsing also the legacy bindings and maybe drop the old driver.
> >>
> >> I assume there are some other common properties you would switch to in
> >> the transition? You could make the legacy driver bail from probe based
> >> on presence or absence of other properties. Or you could just blacklist
> >> converted platforms in the legacy driver. The point is that the problems
> >> are solvable in the kernel.
> >
> > Yes this could be done too. But let's enable it on per-board
> > basis rather than attempt to flip it on at once.
> >
> >> But if your really want a new compatible, I don't really care. It's
> >> only one device.
> >
> > Both a new compatible or a check for some resource work just fine
> > for me as long as the driver can be selected on per-board basis.
>
> New compatible sounds simpler to me since it allows to select a driver per-MMC
> instance. (SDIO support is not added/validated in sdhci-omap).
>
> To summarize, we'll create new compatible and new bindings for sdhci-omap and
> start enabling sdhci-omap on per-board basis. When all the TI platforms starts
> to use sdhci-omap, omap-hsmmc will be removed at which point support for old
> compatible and old dt bindings will be added to sdhci-omap.c. Does this sound
> reasonable?

Sounds like a plan to me.

Regards,

Tony

\
 
 \ /
  Last update: 2017-09-05 18:53    [W:0.063 / U:0.416 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site