Hi,
Can you capture raw bayer images correctly? I assume green
means YUV buffers that are all zero.
Do you know more specifically which patch breaks it?
CCing freemangordon (Ivaylo Dimitrov). He tried to debug it
months ago but without success. Should know more info about this
problem.
I th
Hi Pavel,
On 11/20/2014 01:12 PM, Pavel Machek wrote:
Hi!
I would also swap the segments of a property name to follow the convention
as in case of "regulator-max-microamp".
Updated version:
==
Optional properties for child nodes:
- max
On 11/19/2014 10:45 AM, Jacek Anaszewski wrote:
Hi Pavel, Sakari,
On 11/18/2014 05:51 PM, Pavel Machek wrote:
Hi!
If the hardware LED changes with one that needs different current, the
block for the adp1653 stays the same, but white LED block should be
updated with different value.
I think
Hi!
> >> But regulators already have "regulator-max-microamp" property. So what
> >> about:
> >>
> >> max-microamp : maximum intensity in microamperes of the LED
> >> (torch LED for flash devices)
> >> max-flash-microamp : initial intensity in microamperes of the
> >>
Hi!
> I would also swap the segments of a property name to follow the convention
> as in case of "regulator-max-microamp".
>
> Updated version:
>
> ==
>
> Optional properties for child nodes:
> - max-microamp : maximum intensity in microam
Hi Pavel, Sakari,
On 11/19/2014 06:53 PM, Sakari Ailus wrote:
Hi Jacek and Pavel,
Jacek Anaszewski wrote:
Hi Pavel, Sakari,
On 11/18/2014 05:51 PM, Pavel Machek wrote:
Hi!
If the hardware LED changes with one that needs different current, the
block for the adp1653 stays the same, but white
Hi Pavel,
Pavel Machek wrote:
> On Mon 2014-11-17 07:06:17, Tony Lindgren wrote:
>> * Pali Rohár [141117 07:03]:
>>> On Monday 17 November 2014 15:55:46 Tony Lindgren wrote:
There's nothing stopping us from initializing the camera code
from pdata-quirks.c for now to keep it working
Hi Jacek and Pavel,
Jacek Anaszewski wrote:
> Hi Pavel, Sakari,
>
> On 11/18/2014 05:51 PM, Pavel Machek wrote:
>> Hi!
>>
If the hardware LED changes with one that needs different current, the
block for the adp1653 stays the same, but white LED block should be
updated with differen
Hi Pavel, Sakari,
On 11/18/2014 05:51 PM, Pavel Machek wrote:
Hi!
If the hardware LED changes with one that needs different current, the
block for the adp1653 stays the same, but white LED block should be
updated with different value.
I think that you are talking about sub nodes. Indeed I am
On Mon 2014-11-17 07:06:17, Tony Lindgren wrote:
> * Pali Rohár [141117 07:03]:
> > On Monday 17 November 2014 15:55:46 Tony Lindgren wrote:
> > >
> > > There's nothing stopping us from initializing the camera code
> > > from pdata-quirks.c for now to keep it working. Certainly the
> > > binding
Hi!
> >If the hardware LED changes with one that needs different current, the
> >block for the adp1653 stays the same, but white LED block should be
> >updated with different value.
>
> I think that you are talking about sub nodes. Indeed I am leaning
> towards this type of design.
I think I am
Hi Pavel,
On 11/18/2014 02:21 PM, Pavel Machek wrote:
Hi!
@@ -19,5 +30,10 @@ Examples:
system-status {
label = "Status";
linux,default-trigger = "heartbeat";
+ iout-torch = <500 500>;
+ iout-flash = <1000 1000>;
+ iout-indi
Hi!
> >>>@@ -19,5 +30,10 @@ Examples:
> >>> system-status {
> >>> label = "Status";
> >>> linux,default-trigger = "heartbeat";
> >>>+ iout-torch = <500 500>;
> >>>+ iout-flash = <1000 1000>;
> >>>+ iout-indicator = <100 100>;
> >>>+ flash-timeout
On 11/18/2014 12:32 PM, Pavel Machek wrote:
I've already submitted a patch [1] that updates leds common bindings.
I hasn't been merged yet, as the related LED Flash class patch [2]
still needs some indicator leds related discussion [3].
I think this is a good moment to discuss the flash relate
> >>I've already submitted a patch [1] that updates leds common bindings.
> >>I hasn't been merged yet, as the related LED Flash class patch [2]
> >>still needs some indicator leds related discussion [3].
> >>
> >>I think this is a good moment to discuss the flash related led common
> >>bindings.
On 11/18/2014 09:46 AM, Pavel Machek wrote:
On Tue 2014-11-18 09:09:09, Jacek Anaszewski wrote:
Hi Pavel, Sakari,
On 11/17/2014 03:58 PM, Sakari Ailus wrote:
Hi Pavel,
On Sun, Nov 16, 2014 at 08:59:28AM +0100, Pavel Machek wrote:
For device tree people: Yes, I know I'll have to create file i
On Tue 2014-11-18 09:09:09, Jacek Anaszewski wrote:
> Hi Pavel, Sakari,
>
> On 11/17/2014 03:58 PM, Sakari Ailus wrote:
> >Hi Pavel,
> >
> >On Sun, Nov 16, 2014 at 08:59:28AM +0100, Pavel Machek wrote:
> >>For device tree people: Yes, I know I'll have to create file in
> >>documentation, but does
On Tue 2014-11-18 09:09:09, Jacek Anaszewski wrote:
> Hi Pavel, Sakari,
>
> On 11/17/2014 03:58 PM, Sakari Ailus wrote:
> >Hi Pavel,
> >
> >On Sun, Nov 16, 2014 at 08:59:28AM +0100, Pavel Machek wrote:
> >>For device tree people: Yes, I know I'll have to create file in
> >>documentation, but does
Hi Pavel, Sakari,
On 11/17/2014 03:58 PM, Sakari Ailus wrote:
Hi Pavel,
On Sun, Nov 16, 2014 at 08:59:28AM +0100, Pavel Machek wrote:
For device tree people: Yes, I know I'll have to create file in
documentation, but does the binding below look acceptable?
I'll clean up driver code a bit more
On Monday 17 November 2014 16:06:17 Tony Lindgren wrote:
> * Pali Rohár [141117 07:03]:
> > On Monday 17 November 2014 15:55:46 Tony Lindgren wrote:
> > > There's nothing stopping us from initializing the camera
> > > code from pdata-quirks.c for now to keep it working.
> > > Certainly the binding
On Monday 17 November 2014 16:04:07 Sakari Ailus wrote:
> Hi Pali,
>
> On Mon, Nov 17, 2014 at 04:01:31PM +0100, Pali Rohár wrote:
> > On Monday 17 November 2014 15:55:46 Tony Lindgren wrote:
> > > * Pavel Machek [141117 02:17]:
> > > > On Mon 2014-11-17 11:09:45, Pali Rohár wrote:
> > > > > On M
* Pali Rohár [141117 07:03]:
> On Monday 17 November 2014 15:55:46 Tony Lindgren wrote:
> >
> > There's nothing stopping us from initializing the camera code
> > from pdata-quirks.c for now to keep it working. Certainly the
> > binding should be added to the driver, but that removes a
> > depende
Hi Pali,
On Mon, Nov 17, 2014 at 04:01:31PM +0100, Pali Rohár wrote:
> On Monday 17 November 2014 15:55:46 Tony Lindgren wrote:
> > * Pavel Machek [141117 02:17]:
> > > On Mon 2014-11-17 11:09:45, Pali Rohár wrote:
> > > > On Monday 17 November 2014 11:05:19 Pavel Machek wrote:
> > > > > Hi!
> >
On Monday 17 November 2014 15:55:46 Tony Lindgren wrote:
> * Pavel Machek [141117 02:17]:
> > On Mon 2014-11-17 11:09:45, Pali Rohár wrote:
> > > On Monday 17 November 2014 11:05:19 Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > On Mon 2014-11-17 09:43:19, Pali Rohár wrote:
> > > > > On Sunday 1
Hi Pavel,
On Sun, Nov 16, 2014 at 08:59:28AM +0100, Pavel Machek wrote:
> For device tree people: Yes, I know I'll have to create file in
> documentation, but does the binding below look acceptable?
>
> I'll clean up driver code a bit more, remove the printks. Anything
> else obviously wrong?
Ja
* Pavel Machek [141117 02:17]:
> On Mon 2014-11-17 11:09:45, Pali Rohár wrote:
> > On Monday 17 November 2014 11:05:19 Pavel Machek wrote:
> > > Hi!
> > >
> > > On Mon 2014-11-17 09:43:19, Pali Rohár wrote:
> > > > On Sunday 16 November 2014 08:59:28 Pavel Machek wrote:
> > > > > For device tree
On Mon 2014-11-17 11:09:45, Pali Rohár wrote:
> On Monday 17 November 2014 11:05:19 Pavel Machek wrote:
> > Hi!
> >
> > On Mon 2014-11-17 09:43:19, Pali Rohár wrote:
> > > On Sunday 16 November 2014 08:59:28 Pavel Machek wrote:
> > > > For device tree people: Yes, I know I'll have to create
> > >
On Monday 17 November 2014 11:05:19 Pavel Machek wrote:
> Hi!
>
> On Mon 2014-11-17 09:43:19, Pali Rohár wrote:
> > On Sunday 16 November 2014 08:59:28 Pavel Machek wrote:
> > > For device tree people: Yes, I know I'll have to create
> > > file in documentation, but does the binding below look
> >
Hi!
On Mon 2014-11-17 09:43:19, Pali Rohár wrote:
> On Sunday 16 November 2014 08:59:28 Pavel Machek wrote:
> > For device tree people: Yes, I know I'll have to create file
> > in documentation, but does the binding below look acceptable?
> >
> > I'll clean up driver code a bit more, remove the p
On Sunday 16 November 2014 08:59:28 Pavel Machek wrote:
> For device tree people: Yes, I know I'll have to create file
> in documentation, but does the binding below look acceptable?
>
> I'll clean up driver code a bit more, remove the printks.
> Anything else obviously wrong?
>
> Signed-off-by:
On Sun 2014-11-16 11:09:51, Andreas Färber wrote:
> Hi Pavel,
>
> Am 16.11.2014 um 08:59 schrieb Pavel Machek:
> > For device tree people: Yes, I know I'll have to create file in
> > documentation, but does the binding below look acceptable?
> [...]
> > diff --git a/arch/arm/boot/dts/omap3-n900.dt
Hi Pavel,
Am 16.11.2014 um 08:59 schrieb Pavel Machek:
> For device tree people: Yes, I know I'll have to create file in
> documentation, but does the binding below look acceptable?
[...]
> diff --git a/arch/arm/boot/dts/omap3-n900.dts
> b/arch/arm/boot/dts/omap3-n900.dts
> index 739fcf2..ed0bfc1
On Sun 2014-11-16 09:11:04, Lars-Peter Clausen wrote:
> On 11/16/2014 08:59 AM, Pavel Machek wrote:
> >[...]
> >+adp1653: adp1653@30 {
> >+compatible = "ad,adp1653";
>
> The Analog Devices vendor prefix is adi.
Thanks, will be fixed in next version.
--
(english) http://www.livej
On 11/16/2014 08:59 AM, Pavel Machek wrote:
[...]
+ adp1653: adp1653@30 {
+ compatible = "ad,adp1653";
The Analog Devices vendor prefix is adi.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
Mo
For device tree people: Yes, I know I'll have to create file in
documentation, but does the binding below look acceptable?
I'll clean up driver code a bit more, remove the printks. Anything
else obviously wrong?
Signed-off-by: Pavel Machek
Thanks,
35 matches
Mail list logo
