Hi Mike,
On Tue, Jan 17, 2012 at 18:13:23, Michael Williamson wrote:
> Hello Sudhakar,
>
> On 1/17/2012 12:39 AM, Rajashekhara, Sudhakar wrote:
>
> > Hi Mike,
> >
> > On Mon, Jan 16, 2012 at 20:25:44, Michael Williamson wrote:
> >> Hi,
> >>
> >> I am working with the OMAP-L138 and I think there
Hi Christian,
On Tue, Jan 17, 2012 at 18:23:52, Christian Riesch wrote:
> Hi Sudhakar, hi Mike,
>
> On Tue, Jan 17, 2012 at 1:43 PM, Michael Williamson
> wrote:
> > On 1/17/2012 12:39 AM, Rajashekhara, Sudhakar wrote:
[...]
> >
> > Well, that's all fine and swell, except we have OMAP-L138 plat
Hi Sudhakar,
On Fri, Jan 20, 2012 at 11:01 AM, Rajashekhara, Sudhakar
wrote:
> Hi Christian,
>
> On Tue, Jan 17, 2012 at 18:23:52, Christian Riesch wrote:
>> Hi Sudhakar, hi Mike,
>>
>> On Tue, Jan 17, 2012 at 1:43 PM, Michael Williamson
>> wrote:
>> > On 1/17/2012 12:39 AM, Rajashekhara, Sudhak
add mediabus formats and pixel formats supported
as part of dm365 vpfe device.
The device supports media formats(transfer and storage)
which include-
1: ALAW compressed bayer.
2: UV interleaved without Y (for resizer).
3: YDYC.
Changes from previous version:
1: Added entries in subdev-formats.xml
add new enum entries for supporting the media-bus formats on dm365.
These include some bayer and some non-bayer formats.
V4L2_MBUS_FMT_YDYC8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used
internal to the hardware by the resizer.
V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format
that is supp
add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats
to represent Bayer format frames compressed by A-LAW alogorithm,
add V4L2_PIX_FMT_UV8 to represent storage of C data (UV interleved)
only.
Signed-off-by: Manjunath Hadli
Cc: Laurent Pinchart
---
.../DocBook/media/v4l/pixfmt-srggb10a
Hi Heiko,
On Thu, Jan 19, 2012 at 12:35:21, Heiko Schocher wrote:
> Default queue is expected to be a low-priority queue.
> This way, long transfers on the default queue started
> by the codec engine will not cause audio defects.
>
> Signed-off-by: Heiko Schocher
> Signed-off-by: juha.kui...@gm
Hello.
On 01/12/2012 03:00 PM, Karicheri, Muralidharan wrote:
Sekhar & Sergei,
This will affect the new SoCs that have capabilities to power up different
domains. Why do we need this enforcement? We are working on a DaVinci variant
SoC that can do power up multiple domains
Will their
Commit 5a05a8200a4359ef2bfe9094c137dee35cfdd516 ("davinci_emac:
use an unique MDIO bus name") introduced during the v3.3 merge
window updated the davinci mdio bus name to make it unique.
Update the bus name in board files which use DaVinci MDIO bus
to match the new name. Without this PHY is not de
