lkml.org 
[lkml]   [2013]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2] ADP1653 board code for Nokia RX-51
Date
Hi Sakari,

On Thursday 04 April 2013 01:22:28 Sakari Ailus wrote:
> On Tue, Mar 26, 2013 at 12:07:01AM +0100, Laurent Pinchart wrote:
> > On Sunday 24 March 2013 23:46:01 Sakari Ailus wrote:
> > > Pali Rohár wrote:
> > > > On Thursday 07 March 2013 23:18:27 Sakari Ailus wrote:
> > > >> On Wed, Mar 06, 2013 at 10:44:41PM +0100, Sebastian Reichel wrote:
> > > >>> On Wed, Mar 06, 2013 at 09:20:16PM +0100, Pali Rohár wrote:
> > > >>>> On Wednesday 06 March 2013 21:12:06 Pali Rohár wrote:
> > > >>>>> On Sunday 17 February 2013 20:03:03 Aaro Koskinen wrote:
> > > >>>>>> On Sun, Feb 17, 2013 at 04:16:49PM +0100, Pali Rohár wrote:
> > > >>>>>>> +/*
> > > >>>>>>> + * arch/arm/mach-omap2/board-rx51-camera.c
> > > >>>>>>> + *
> > > >>>>>>> + * Copyright (C) 2008 Nokia Corporation
> > > >>>>>>> + *
> > > >>>>>>> + * Contact: Sakari Ailus <sakari.ailus@nokia.com>
> > > >>>>>>> + * Tuukka Toivonen <tuukka.o.toivonen@nokia.com>
> > > >>>>>>
> > > >>>>>> You should put these people to CC... Just to see if the addresses
> > > >>>>>> are still valid (which I doubt).
> > > >>>>>
> > > >>>>> Ok, trying :-)
> > > >>>>
> > > >>>> I got "Delivery Status Notification (Failure)" for both addresses.
> > > >>
> > > >> This is expected.
> > > >>
> > > >>> Sakari Ailus hosts some code on github [0], which has the following
> > > >>> email address:
> > > >>> sakari.ailus+gitorious@retiisi.org.uk
> > > >>>
> > > >>> I added it to this mail's CC.
> > > >>>
> > > >>> [0] https://gitorious.org/~sailus
> > > >>
> > > >> Nice to hear people are interested in this. ;-)
> > > >>
> > > >> The primary reason I haven't tried submitting this to mainline is
> > > >> that ARM board code has a bad reputation these days. The N900 does
> > > >> not have yet support for device tree (AFAIK), which also would
> > > >> require a few bits and pieces on the flash driver to work.
> > > >>
> > > >> Also the sensor and lens drivers would need at least some work before
> > > >> being ready for submission to mainline for camera to be usable.
> > > >> Unfortunately I haven't had recently time to work on this. N9(50)
> > > >> support has higher priority for myself. That, too, is pending the DT
> > > >> support for the device.
> > > >>
> > > >> There's indeed more up-to-date code in my repository. Even if it's
> > > >> not too close to mainline anymore it should be a better starting
> > > >> point than the old kernel from MeeGo.
> > > >>
> > > >> <URL:https://gitorious.org/omap3camera/pages/Home>
> > > >
> > > > Hi,
> > > >
> > > > this board code is same in your git repository and on meego obs.
> > > >
> > > > Patch only adding support for adp1653 driver which is already in
> > > > upstream kernel.
> > > >
> > > > Are there any other problems with this patch to go for upstream?
> > >
> > > A few more things comes to mind. We depend a little bit on actual board
> > > code; it's not only static data. That's the configuration of the
> > > external clock from the ISP to the sensor. That should move to the
> > > common clock framework so that the ISP registers the clock and the
> > > sensor driver can then use it. AFAIR Laurent has done some work on that.
> >
> > Yes. I hope to get the patches in v3.10.
>
> Cool! :)

The patches have been posted to the linux-media mailing list. If the
dependencies make it to v3.10 the OMAP3 ISP patches should get there too.

> > > The peculiar detail of the rx51 is that there's a switch on the camera
> > > CCP2 bus that selects either sensor (primary or secondary). Both sensors
> > > are connected to the same receiver. That isn't properly modelled
> > > currently at all, so that's why we have rx51_camera_set_xshutdown(). I
> > > guess it'd still work if you only power (i.e. open) either of the
> > > devices at a time, though.
> >
> > Have you thought about how we could model that ?
>
> Well, the two dependent gpios could be modelled as two independent ones (
> for sensor drivers), but setting the state of those gpios could fail,
> gpio_set_value() still returns void. This isn't pretty perhaps but as a
> result the initialisation of the secondary sensor to be powered up at the
> same time will fail since it's in reset: the xshutdown of both sensors is
> controlled by the same gpio as is the mux (AFAIR).
>
> So one N900 camera specific gpio driver would be needed. It'd be a very
> simple driver. What do you think?

I think I'll need to see how the GPIOs are wired up on the board.

--
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2013-04-04 15:43    [W:0.071 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site