Hi Niklas, On Mon, Jun 04, 2018 at 02:25:15PM +0200, Simon Horman wrote: > On Mon, Jun 04, 2018 at 01:31:54PM +0200, Niklas Söderlund wrote: > > Hi Simon, > > > > On 2018-06-04 11:53:09 +0200, Simon Horman wrote: > > > On Mon, May 21, 2018 at 07:27:43PM +0200, Jacopo Mondi wrote: > > > > > > > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN > > > > driver and only confuse users. Remove them in all Gen2 SoC that use > > > > them. > > > > > > I think that the rational for removing properties (or not) is their > > > presence in the bindings as DT should describe the hardware and not the > > > current state of the driver implementation. > > > > > > I see that 'bus-width' may be removed from the binding, as per discussion > > > in a different sub-thread. I'd like that discussion to reach a conclusion > > > before considering that part of this patch any further. > > > > > > And I'd appreciate Niklas's feedback on the 'pclk-sample' portion. > > > > My thoughts on 'pclk-sample' is the same as for 'bus-width', they > > describe the hardware. So we either should keep or remove both. As our > > discussion in the other thread I'm leaning towards that both should be > > kept. Am I wrong, or we discussed about the face there is no way to specify the bus widht of the VIN parallel input interface? > > Thanks, that sounds reasonable to me. So they should be documented if we want to keep them. Currently, they are not. And again, someone integrating a sensor may try to play around with those properties, expecting them to change the interface behavior and wasting time trying to figure out where the error is, on sensor side or VIN side, before realizing those properties are actually ignored. Anyway, the most important thing, if we want to keep them is to provide a patch to document them as optional properties of the VIN endpoint. Thanks j > > I'm marking (v4 of) this as deferred pending a conclusion to that > conversation. >
Attachment:
signature.asc
Description: PGP signature
