All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Hans Verkuil" <hverkuil@xs4all.nl>
To: "Karicheri, Muralidharan" <m-karicheri2@ti.com>
Cc: "Guennadi Liakhovetski" <g.liakhovetski@gmx.de>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	"Sakari Ailus" <sakari.ailus@maxwell.research.nokia.com>,
	"Laurent Pinchart" <laurent.pinchart@skynet.be>
Subject: RE: RFC: bus configuration setup for sub-devices
Date: Mon, 31 Aug 2009 17:07:34 +0200	[thread overview]
Message-ID: <3b674866ac8647a2fddfa9e3cee94cdb.squirrel@webmail.xs4all.nl> (raw)
In-Reply-To: <A69FA2915331DC488A831521EAE36FE40154EDC3DC@dlee06.ent.ti.com>


>>>
>>> Up to now I usually saw the master-slave relationship defined as per
>>> whether the protocol is "master" or "slave," which always was used from
>>> the PoV of the bridge. I.e., even in a camera datasheet a phrase like
>>> "supports master-parallel mode" means supports a mode in which the
>>> bridge
>>> is a master and the camera is a slave. So, maybe it is better instead
>>> of
>>a
>>> .is_master flag to use a .master_mode flag?
>>
>>Sounds reasonable. I'll check a few datasheets myself to see what
>>terminology
>>they use.
>
> Master/Slave is always confusing to me. In VPFE, it can act as master
> (when it output sync signal and pixel clock) and slave (when it get sync
> signal from sensor/decoder). We use VPFE as slave and sensor/decoder will
> provide the pixel clock and sync signal. Please confirm if this is what
> master_mode flag means.

That's correct: the master provides the pixel clock signal. I'm not sure
if it also means that the syncs are provided by the master. Do you know?

Regards,

         Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG


  reply	other threads:[~2009-08-31 15:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-29 14:31 RFC: bus configuration setup for sub-devices Hans Verkuil
2009-08-30 15:46 ` Hiremath, Vaibhav
2009-08-30 19:35   ` Hans Verkuil
2009-08-30 22:19 ` RFC: " Guennadi Liakhovetski
2009-08-31  6:23   ` Hans Verkuil
2009-08-31 14:45     ` Karicheri, Muralidharan
2009-08-31 15:07       ` Hans Verkuil [this message]
2009-08-31 15:12         ` Karicheri, Muralidharan
2009-08-31 16:11         ` Guennadi Liakhovetski
2009-08-30 22:31 ` Laurent Pinchart
2009-08-31  6:33   ` Hans Verkuil
2009-08-31 14:42 ` Karicheri, Muralidharan
2009-08-31 17:23   ` Hans Verkuil
2009-08-31 15:54 ` RFC: " Sakari Ailus
2009-08-31 16:08   ` Guennadi Liakhovetski
2009-08-31 16:54   ` Karicheri, Muralidharan
2009-08-31 17:42   ` Hans Verkuil
2009-08-31 17:53     ` Guennadi Liakhovetski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3b674866ac8647a2fddfa9e3cee94cdb.squirrel@webmail.xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=g.liakhovetski@gmx.de \
    --cc=laurent.pinchart@skynet.be \
    --cc=linux-media@vger.kernel.org \
    --cc=m-karicheri2@ti.com \
    --cc=sakari.ailus@maxwell.research.nokia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.