Re: [PATCH v2] video: s3c-fb: Add device tree support

[Shawn Guo]

On Fri, Mar 30, 2012 at 09:25:14PM +0530, Rabin Vincent wrote:
> On Fri, Mar 30, 2012 at 11:23, Thomas Abraham  
> wrote:
> > +    - samsung,fimd-display: The fimd controller is interfaced with the a
> > +      display device such as a lcd panel. This property should specify the
> > +      phandle of the display device node. For a display device node that
> > +      represents a RGB type display interface, it is expected to specify 
> > the
> > +      video interface timing using the following properties.
> > +
> > +      - lcd-htiming: Specifies the horizontal timing for the overlay. The
> > +        horizontal timing includes four parameters in the following order.
> > +
> > +        - horizontal back porch (in number of lcd clocks)
> > +        - horizontal front porch (in number of lcd clocks)
> > +        - hsync pulse width (in number of lcd clocks)
> > +        - Display panels X resolution.
> > +
> > +      - lcd-vtiming: Specifies the vertical timing for the overlay. The
> > +        vertical timing includes four parameters in the following order.
> > +
> > +        - vertical back porch (in number of lcd lines)
> > +        - vertical front porch (in number of lcd lines)
> > +        - vsync pulse width (in number of lcd clocks)
> > +        - Y resolution.
> 
> In this old thread, it was suggested to use a raw EDID block to supply
> timings, and since then a couple of drivers in mainline (sm501fb and
> fsl-diu) are doing it that way:
> 
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-February/080683.html
> 
> Shouldn't this driver be doing the same thing?  If not, shouldn't
> whatever interface this is adding be provided in a common helper (like
> that old patch was trying to add) so it's standardized between drivers?

+1

We need a generic binding for the data defined in "struct fb_videomode"
and a generic helper function to retrieve the data from device tree,
so that individual display driver does not have to invent their owns.

-- 
Regards,
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support

[Chris Ball]

Hi Kukjin,

On Wed, Mar 28 2012, Kukjin Kim wrote:
>>> As a result I'm dropping this tree -- and all of the patches that I
>>> have on top of it -- from mmc-next so that I can get a pull request
>>> out.  This means that I'm dropping:
>>
> Hmm, I think, if you're ok, you can send a second pull request to
> Linus for it and actually, it is in linux-next for a long time via mmc
> and samsung tree.
>
> Note, please don't rebase it because its resolution for conflicts is
> in linux-next and I think Linus will use it when happens
> conflicts...Or I can provide new tree on top of latest mainline. But
> I'm not sure about latter.

I can't send the tree as it is to Linus now, because Arnd has asked us
to hold off on these device tree bindings and work with the unified
bindings he's proposing instead.  (Rebasing to drop that patch will
introduce new conflicts.)

I'm going to send Mark Brown's two patches to Linus now, even though it
will cause a conflict in -next.  The rest (other than the device tree
bindings) are mergable after -rc1, because they're fixes, so we'll
eventually get everything except DT in to 3.4.  I think you should
just drop this patchset from your tree in linux-next entirely now.

Thanks,

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html