Fri, 23 May 2014 15:43:40 +0300 от Tomi Valkeinen <tomi.valkeinen@xxxxxx>:
> On 18/05/14 15:01, Alexander Shiyan wrote:
> > Fri, 16 May 2014 15:56:26 -0700 от Olof Johansson <olof@xxxxxxxxx>:
> >> On Thu, May 08, 2014 at 01:14:40PM +0300, Tomi Valkeinen wrote:
> >>> On 08/05/14 11:27, Alexander Shiyan wrote:
> >>>
> >>>>>> At this time the driver has three user.
> >>>>>> Only one of them should theoretically work.
> >>>>>> clps711x-autcpu12 should not work in the absence of memblock_reserve().
> >>>>>> clps711x-p720t should not work due to physical address limitation as i
> >>>>>> noticed before. Board means to use SRAM instead of SDRAM.
> >>>>>> Only clps711x-edb7211 should work fine (in theory).
> >>>>>> Is this a good reason to replace the driver? I think yes.
> >>>>>
> >>>>> Ok, if the situation is that bad, maybe we can just switch to the new
> >>>>> driver. Have you verified that those boards do not work from anyone? Or
> >>>>> asked someone to test the new driver with those boards?
> >>>>
> >>>> I'm not familiar with other users of this platform .
> >>>> I am do not have these boards, all that I have written before that it's just a theory.
> >>>> Firm in which I work, uses its own board with CLPS711X CPU , this board is the
> >>>> only way to check for changes on real hardware .
> >>>
> >>> Ok. That makes me a bit nervous... You're removing a driver, which may
> >>> (or may not) have been working for other users. And adding a new one,
> >>> which may not (or may) work for the other users.
> >>
> >> Keep the old one around under another Kconfig name, mark it BROKEN,
> >> and if nobody speaks up in a couple of releases, remove it?
> >
> > I like this variant, Tomi are you agree with this?
>
> I don't know. All options sound somewhat bad to me, except if it's clear
> nobody uses the old driver.
>
> Anyway, it's rather late for 3.16. I'd like the removal of the old
> driver to sit in the linux-next for a while.
>
> Would it be possible to add the new driver along the old driver, and use
> the new driver only for the boards you have, and for boards for which
> it's clear the the old driver is not working? This could be merged for 3.16.
At this time yes, we can. But since I plan to add multiplatform support
for this SOC, this seems not possible.
I can try to make multiplatform support optional, then it could be done...
> It's not so nice to have two drivers for the same hardware, but in this
> case maybe that's not an issue. The old driver doesn't support DT, so no
> conflicts there, and for non-DT the driver names seem to be different.
>
> For 3.17, we could remove the old driver, and push that change to
> linux-next right after the 3.16 merge window has closed.
>
> Or, if you're fine with it, we can also delay adding the new driver to
> 3.17, and do both right after the 3.16 merge window has closed. I
> personally like this most, so that we have both removal of the old and
> adding the new sitting in the linux-next longer, but you might possibly
> want the new driver in sooner.
If there will be two drivers, I will do the following: remove the non-DT
support (for new driver) and will create a patch for 3.16 (this patch will
no affect to arm-soc).
After that, I will do optional multiplatform support for this CPU and move
the boards, which do not use FB.
After this architecture will be ready to add DT support, and after all boards
will be converted, I'll remove the old version of the driver.
OK?
---
��.n��������+%������w��{.n�����{����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
