Dear Pavel Herrmann,
> On Friday 21 of September 2012 20:01:27 Marek Vasut wrote:
> > Dear Pavel Herrmann,
> >
> > > On Friday 21 of September 2012 18:08:13 Marek Vasut wrote:
> > > > Dear Pavel Herrmann,
> > > >
> > > > > On Friday 21 of September 2012 17:39:21 Marek Vasut wrote:
> > > > > > Dear Pavel Herrmann,
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > > > Can't the old driver just have a compat section in them? Like
> > > > > > > > I did with serial stuff:
> > > > > > > >
> > > > > > > > 1) rename the internal functions to
> > > > > > > > ${driver}_${function_name} from pure ${function_name} and
> > > > > > > > introduce section which behaves as a wrapper (implement
> > > > > > > > ${function_name} calling
> > > > > > > > ${driver}_${function_name} ). 2) Add your DM goo, implement
> > > > > > > > #ifdef around it so either the compat section or DM section
> > > > > > > > is enabled.
> > > > > > >
> > > > > > > I actually did something of this sort, see [4/11], with less
> > > > > > > touching.
> > > > > > >
> > > > > > > the problem is that while SATA drivers are easy to convert, IDE
> > > > > > > ones are not. I would actually propose to do a ide_legacy
> > > > > > > driver (mostly out of the code currently in common/cmd_ide.c),
> > > > > > > and keep it as the only option until IDE dies completely.
> > > > > >
> > > > > > IDE will be around for a LONG time.
> > > > > >
> > > > > > You introduce that CONFIG_SYS_SATA_LEGACY for no reason, if you
> > > > > > did it as
> > > > > > said above, simple CONFIG_DM would suffice as the drivers would
> > > > > > be intacts with DM disabled. Note the compiler will opt-out
> > > > > > these proxy calls.
> > > > > >
> > > > > > Besides, with this approach of yours, you need to enable
> > > > > > SATA_LEGACY for every single board now, introducing a lot of
> > > > > > churn into the patches and if it's not defined, every board
> > > > > > using SATA is broken, right?
> > > > >
> > > > > No, if you dont define CONFIG_DM, you get the old way of
> > > > > interacting with disks. only if you define CONFIG_DM you only need
> > > > > CONFIG_SATA_LEGACY to plug old SATA drivers into DM codepaths
> > > >
> > > > So if you enable DM for a board, you also need to enable this compat
> > > > layer? My opinion is, that you either enable DM on the board and the
> > > > board is ready for it or don't enable it.
> > >
> > > if you enable DM on a board, you can either use the compat layer and
> > > the old driver, or use a ported driver and get rid of the compat layer
> > >
> > > > Would you need the compat layer at all were you to follow my advice?
> > >
> > > if i understand what you meant, i would build this compat layer into
> > > every one of the drivers currently in tree (with some cleanup). in
> > > that case, i would not need it
> >
> > That's correct. You would prepare every driver to be DM-ish and the final
> > deployment of DM would be mechanical. So would be the removal of the
> > non-DM part later on.
>
> that would lead to massive code duplication.
How?
> im not talking about the SATA
> drivers now, there its just about ready for DM already (static for all
> functions, remove dependency on static block_dev_desc array, include driver
> registration functions, done), but about IDE drivers, where the drivers
> have ~200 lines, whereas cmd_ide.c has ~2000 lines.
IDE implements some nasty hooks into cmd_ide.c, right ? I think if you managed
to clean up and analyze cmd_ide.c, it'd be possible to figure out a path to fix
the IDE drivers.
> as for the SCSI
> drivers, ahci.c is not really SCSI, more like a SATA driver with SCSI
> wrapper built in, the other one is a bit more complex, and would require
> some wrapper code addition (cmd_scsi is ~600 lines)
Might need some thinking here. Can the SCSI handling be abstracted out?
[...]
Best regards,
Marek Vasut
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
