Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Wed, 7 May 2014 12:40:49 +0300 от Tomi Valkeinen <tomi.valkeinen@xxxxxx>:
> On 30/04/14 15:36, Alexander Shiyan wrote:
> 
> >> Hmm what? So is the old driver totally broken, and cannot be used at the
> >> moment? Or why you can't test on real hardware?
> > 
> > Firstly, the driver uses a fixed values for xres, yres, pixclock and specific
> > variable ac_precale.
> > Secondly, the driver uses a fixed value for the physical address of the buffer.
> > Totally, it does not give me the ability to use the driver in the current state.
> > Unlikely that this will look good if I make these two significant changes in
> > a single patch...
> > 
> > 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 .

> I'm still not really happy about it, and I'd much rather see the current
> driver fixed. But if no one having those boards is up to the task
> (probably not if they have not been working at all), maybe just ditching
> the old driver and adding a new is the only way forward.
> 
> One change that I think would be good is to change the series to first
> remove the old driver, and then add the new one, with the same file name
> as the old one. That way git log will show the history for both the new
> and the old driver.

In this case git-bisect will be broken. Is this OK?

---

��.n��������+%������w��{.n�����{����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�


[Index of Archives]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Tourism]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux