Hi Laurent,
On mié 13-05-2020 17:08:32, Laurent Pinchart wrote:
> The driver doesn't apply any setting to the device :-) The ti,deskew
> property is meant to report the deskew settings selected by the chip's
> configuration pins, not to set a value to be programmed to the device.
Oh, I see,
Hi Ricardo,
On Wed, May 13, 2020 at 01:09:57PM +0200, Ricardo Cañuelo wrote:
> On mié 06-05-2020 18:53:20, Laurent Pinchart wrote:
> > I didn't if I remember correctly, I just mapped it to the hardware
> > features. The hardware register indeed takes a value between 0 and 7,
> > and that is
Hi Laurent,
On mié 06-05-2020 18:53:20, Laurent Pinchart wrote:
> I didn't if I remember correctly, I just mapped it to the hardware
> features. The hardware register indeed takes a value between 0 and 7,
> and that is mapped to [-4,3] x t(STEP). I don't mind either option.
I was taking a look
On Mon, May 11, 2020 at 04:59:11PM +0200, Ricardo Cañuelo wrote:
> Hi Rob,
>
> What's your opinion on this?
>
> Some context: It's about bindings that define signed integer properties
> with range checks that go below and above zero. The schema checker fails
> because, apparently, it interprets
Hi Ricardo.
On Mon, May 11, 2020 at 04:59:11PM +0200, Ricardo Cañuelo wrote:
> Hi Rob,
>
> What's your opinion on this?
I'm not Rob, but anyway.
>
> Some context: It's about bindings that define signed integer properties
> with range checks that go below and above zero. The schema checker
Hi Rob,
What's your opinion on this?
Some context: It's about bindings that define signed integer properties
with range checks that go below and above zero. The schema checker fails
because, apparently, it interprets every cell value as an uint32, which
makes the range check fail for negative
Hi Tomi,
On Tue, Apr 28, 2020 at 12:49:28PM +0300, Tomi Valkeinen wrote:
> On 28/04/2020 12:20, Ricardo Cañuelo wrote:
>
> > 2) The definition of ti,deskew in the original binding seems to be
> > tailored to the current driver and the way it's defined may not be very
> > DT-friendly.
> >
> >
On 06/05/2020 11:28, Ricardo Cañuelo wrote:
Hi Tomi,
On mié 06-05-2020 11:01:07, Tomi Valkeinen wrote:
Doesn't all this just point to a bug or missing feature in dt_binding_check?
That's not a reason to change the ABI.
I agree and I'd vote for "missing feature", but seeing that there aren't
Hi Ricardo,
On 06/05/2020 10:21, Ricardo Cañuelo wrote:
Hi Tomi, thanks for reviewing the patch.
On mar 28-04-2020 12:49:28, Tomi Valkeinen wrote:
I don't quite understand this. We cannot have negative numbers in dts files?
Or we can, but dt_binding_check doesn't handle them correctly? Or
Hi Tomi,
On mié 06-05-2020 11:01:07, Tomi Valkeinen wrote:
> Doesn't all this just point to a bug or missing feature in dt_binding_check?
> That's not a reason to change the ABI.
I agree and I'd vote for "missing feature", but seeing that there aren't
any other examples of this use case in the
Hi Tomi, thanks for reviewing the patch.
On mar 28-04-2020 12:49:28, Tomi Valkeinen wrote:
> I don't quite understand this. We cannot have negative numbers in dts files?
> Or we can, but dt_binding_check doesn't handle them correctly? Or that int32
> is not supported in yaml bindings?
AFAICT,
On mar 28-04-2020 21:21:17, Sam Ravnborg wrote:
> Hi Ricardo.
>
> Thanks for looking into this bridge binding.
> Some comments in the following.
Thanks for reviewing it, Sam. I agree with your suggestions, some
comments below:
> Can you define it as an enum like this:
>
> enum: [-4, -3,
Hi Ricardo.
Thanks for looking into this bridge binding.
Some comments in the following.
Sam
On Tue, Apr 28, 2020 at 11:20:48AM +0200, Ricardo Cañuelo wrote:
> Convert the DT binding documentation for the TI TFP410 DPI-to-DVI
> encoder to json-schema.
>
> Signed-off-by: Ricardo Cañuelo
On 28/04/2020 12:20, Ricardo Cañuelo wrote:
2) The definition of ti,deskew in the original binding seems to be
tailored to the current driver and the way it's defined may not be very
DT-friendly.
This parameter maps to a 3-bit field in a hardware register that takes
a value from 0 to 7,
14 matches
Mail list logo