Re: [RFC v3][PATCH 0/4] OMAP: DSS2: Overlay Manager LCD2 support in DISPC

[Tomi Valkeinen <tomi.valkeinen@nokia.com>]

Hi,

On Tue, 2010-10-05 at 13:55 +0200, ext Archit Taneja wrote:
> This patch series which incorporates changes in DSS2 to enable
> omap_dss_device instances to use the new Overlay Manager LCD2 in
> DISPC.
> 
> On OMAP4, we have a new DISPC channel for Overlay Manager LCD2. This
> channel's video port is a source port for RFBI, DSI2 and DPI. The
> Primary channel's video port is connected to RFBI and DSI1.
> 
> There is a set of regsiters for LCD2 channel similar to the existing
> LCD channel, like DISPC_CONTROL2, DISPC_DIVISOR2, DISPC_CONFIG2 and so
> on.
> 
> In order to decide which LCD Overlay Manager to configure(LCD/LCD2),
> there is a need for the omap_dss_device instances to tell the interface
> drivers(DSI, DPI, RFBI etc) which LCD channel they want to connect to, so
> that the corresponding registers get configured. Therefore, a new
> enum omap_channel member is introduced to omap_dss_device.
> 
> This design was made keeping in mind the possible addition of more
> Overlay Managers in future OMAPs, this code is also backward compatible
> with OMAP3 as omap_dss_device instances in OMAP3 will stick only with
> OMAP_DSS_CHANNEL_LCD.
> 
> This will apply over the set of dss_feature framework patches:
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34768.html

The patchset makes dispc API changes in patch 2, but doesn't change any
of the code that uses that API. This means that the kernel doesn't
compile after applying patch 2.

The kernel has to be compilable and working after each patch, so that is
not acceptable.

Fixing that in easy way would mean squashing the later patches together
with patch 2, but that would result in a huge patch, and patch 2 is
already very big. Thus I'd suggest doing the changes in smaller bits.

You could first add the register definitions, and make the changes in
dispc.c to keep everything working. After that you could change the
dispc functions, one by one or in small groups (depending on the amount
of changes), and add the channel argument and adjusting the code using
those functions in the same time.

This would solve the problem of keeping the kernel working, and would
make the patches much more readable.

 Tomi