On Tue, Oct 2, 2018 at 2:26 PM Timur Tabi wrote:
> On 10/2/18 2:38 AM, Linus Walleij wrote:
> >> But as today the only driver that seems to be using valid_mask is msm,
> >> so perhaps a hack is something better and then when we have a second
> >> driver that requires it we figure out the real requ
On 10/2/18 2:38 AM, Linus Walleij wrote:
But as today the only driver that seems to be using valid_mask is msm,
so perhaps a hack is something better and then when we have a second
driver that requires it we figure out the real requirements. But it is
definately your decision;)
Please note that
On Tue, Oct 2, 2018 at 9:15 AM Ricardo Ribalda Delgado
wrote:
> On Mon, Oct 1, 2018 at 11:20 PM Linus Walleij
> wrote:
> > gpiochip_add_data() doesn't allocate anything, it
> > just adds a already allocated (or static!) gpio_chip
> > to the gpiolib subsystem.
>
> Take a look to gpiochip_add_dat
Hi
On Mon, Oct 1, 2018 at 11:20 PM Linus Walleij wrote:
>
> On Mon, Oct 1, 2018 at 3:36 PM Ricardo Ribalda Delgado
> wrote:
> > On Mon, Oct 1, 2018 at 1:54 PM Linus Walleij
> > wrote:
> > > On Fri, Sep 28, 2018 at 9:30 PM Ricardo Ribalda Delgado
> > > wrote:
> > >
> > > > How do we proceed fro
On Mon, Oct 1, 2018 at 3:36 PM Ricardo Ribalda Delgado
wrote:
> On Mon, Oct 1, 2018 at 1:54 PM Linus Walleij wrote:
> > On Fri, Sep 28, 2018 at 9:30 PM Ricardo Ribalda Delgado
> > wrote:
> >
> > > How do we proceed from here? Can you fix your driver somehow to
> > > init the valid mask before en
On 10/1/2018 7:36 AM, Ricardo Ribalda Delgado wrote:
Hi Linus
On Mon, Oct 1, 2018 at 1:54 PM Linus Walleij wrote:
On Fri, Sep 28, 2018 at 9:30 PM Ricardo Ribalda Delgado
wrote:
How do we proceed from here? Can you fix your driver somehow to
init the valid mask before enabling the gpio?
Ju
Hi Linus
On Mon, Oct 1, 2018 at 1:54 PM Linus Walleij wrote:
>
> On Fri, Sep 28, 2018 at 9:30 PM Ricardo Ribalda Delgado
> wrote:
>
> > How do we proceed from here? Can you fix your driver somehow to
> > init the valid mask before enabling the gpio?
>
> Just include a hunk to the qcom driver reor
On Fri, Sep 28, 2018 at 9:30 PM Ricardo Ribalda Delgado
wrote:
> How do we proceed from here? Can you fix your driver somehow to
> init the valid mask before enabling the gpio?
Just include a hunk to the qcom driver reordering this call
at the same time. No need to make it separate patches,
it n
On 9/29/18 8:21 AM, Timur Tabi wrote:
Is it possible to access the hardware?
Linaro and some Linux OSVs should still have systems, but I usually just
ask Jeff to test code for me.
Alternatively, you can just add valid_mask support to your driver, and
add a check to your get_direction() fu
On 9/29/18 1:23 AM, Ricardo Ribalda Delgado wrote:
In fact gpiochip_init_valid_mask is called some lines after in the
same function. We could reorder the function. Would that work for you?
It might. It might break something else, though.
The driver breaking is upstream?
Yes.
Is it possi
Hi Timur
In fact gpiochip_init_valid_mask is called some lines after in the
same function. We could reorder the function. Would that work for you?
The driver breaking is upstream? Is it possible to access the hardware?
Thanks
[Sorry for the two html mails in a row, I did not try to work with m
On Fri, Sep 28, 2018 at 2:14 PM Jeffrey Hugo wrote:
> Nack. Causes a XPU violation to the GPIO config registers.
That doesn't surprise me at all.
I believe that the problem is that gpiochip_line_is_valid() is being
called before gpiochip_irqchip_init_valid_mask() is called, which
means that gpi
On 9/27/2018 8:04 AM, Jeffrey Hugo wrote:
On 9/27/2018 6:19 AM, Timur Tabi wrote:
On 9/27/18 1:51 AM, Stephen Boyd wrote:
Looks OK to me visually. I haven't tested it because I don't have access
to the locked down hardware anymore.
Same here. Please wait for Jeff Hugo to test it before apply
On 9/27/2018 8:19 AM, Timur Tabi wrote:
On 9/27/18 9:04 AM, Jeffrey Hugo wrote:
I guess its lucky I saw this then.
Did you not get this email:
https://lore.kernel.org/patchwork/patch/989545/#1173771
Apparently I did. I found it in my deleted items. I must have
accidentally done that whe
On 9/27/18 9:04 AM, Jeffrey Hugo wrote:
I guess its lucky I saw this then.
Did you not get this email:
https://lore.kernel.org/patchwork/patch/989545/#1173771
On 9/27/2018 6:19 AM, Timur Tabi wrote:
On 9/27/18 1:51 AM, Stephen Boyd wrote:
Looks OK to me visually. I haven't tested it because I don't have access
to the locked down hardware anymore.
Same here. Please wait for Jeff Hugo to test it before applying. Thanks.
I guess its lucky I saw thi
On 9/27/18 1:51 AM, Stephen Boyd wrote:
Looks OK to me visually. I haven't tested it because I don't have access
to the locked down hardware anymore.
Same here. Please wait for Jeff Hugo to test it before applying. Thanks.
Quoting Ricardo Ribalda Delgado (2018-09-21 03:36:04)
> Current code assumes that the direction is input if direction_input
> function is set.
> This might not be the case on GPIOs with programmable direction.
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
Looks OK to me visually. I haven't te
Jeff, can you test these two patches on Amberwing to make sure that they
don't cause an XPU violation on boot?
The call to gpiochip_line_is_valid() should return false on any GPIOs
that aren't listed in the ACPI table.
My concern is that this patch might be calling gpiochip_line_is_valid()
t
Current code assumes that the direction is input if direction_input
function is set.
This might not be the case on GPIOs with programmable direction.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/gpio/gpiolib.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/driver
20 matches
Mail list logo
