Linus responded in v2 mail thread that he's gonna take it instead of v1.
2018-03-02 9:14 GMT+01:00 Alexandre Torgue :
> Hi Radoslaw and Linus,
>
>
> On 03/01/2018 10:24 PM, Radosław Pietrzyk wrote:
>>
>> I don't know if Alexandre agrees but It might be better to
I don't know if Alexandre agrees but It might be better to take v2
where irq_ack is added.
2018-03-01 22:04 GMT+01:00 Linus Walleij :
> On Wed, Feb 21, 2018 at 2:50 PM, Radoslaw Pietrzyk
> wrote:
>
>> - removes unneeded irq_chip.irq_eoi callback
>> - adds irq_chip.irq_set_wake cal
I don't fully get it to be honest. If interrupt is pending it must
have been enabled (unmasked) and requires to be handled acked. It will
be acked by irq_chip.irq_ack handler within the edge handler.
Therefore this additional acking is meaningless.
2018-02-23 16:46 GMT+01:00 Ludovic BARRE :
> hi R
I think the HW is fairly simple and straightforward comparing to other
irq chips so it's rather a logic that concerned me the most i.e. why
gpio irqs were handled in a "simple" manner whereas the rest of
interrupts in "edge" manner. According to specification all interrupts
are edge driven and that
Hi Ludovic,
Please check latest v2 patches series and let me know if it works on
stm32h7 as it does on stm32f4
2018-02-22 12:01 GMT+01:00 Radosław Pietrzyk :
> Hi Ludovic,
> I have tested on stm32f429-disco and it works without a problem.
> handle_edge_irq is not used in current imple
Hi Ludovic,
I have tested on stm32f429-disco and it works without a problem.
handle_edge_irq is not used in current implementation because it is
substituted by handle_simple_irq in an alloc callback either way which
causes that irq_ack callback is not invoked as well (acking is done in
chained hand
g this patch.
> The impact is genuine and has to be tested thoroughly before granting an ack.
>
> Thus I prefer having a better understanding of the issue.
> I will try to work on this later on.
>
> Regards
>
>
> On 12/07/2017 11:52 AM, Wolfram Sang wrote:
>> On Tue, Oct
I'm afraid that didn't help and the problem still exists even with
those patches applied.
2017-10-17 16:35 GMT+02:00 Pierre Yves MORDRET :
>
>
> On 10/17/2017 03:51 PM, Radosław Pietrzyk wrote:
>> I can try of course but it means that any IRQ delay may cause the same
>
I can try of course but it means that any IRQ delay may cause the same
problem so the question is whether the driver should be vulnerable to
such use cases.
2017-10-17 15:18 GMT+02:00 Pierre Yves MORDRET :
>
>
> On 10/12/2017 11:55 AM, Radosław Pietrzyk wrote:
>> It looks like ther
It looks like there is a use case when IRQ handler is delayed a bit
and the logic in the driver does not work. What is the real root cause
I don't know.
2017-10-12 11:31 GMT+02:00 Pierre Yves MORDRET :
>
>
> On 10/11/2017 01:53 PM, Radoslaw Pietrzyk wrote:
>> Do not read data on RXNE but on
Understood
2017-03-13 12:19 GMT+01:00 Dan Carpenter :
> On Mon, Mar 13, 2017 at 12:16:13PM +0100, Radosław Pietrzyk wrote:
>> Ok I will. I just have thought that in general it might be helpful to
>> have this possibility as DT is parsed for this option anyway. If you
>> thin
13, 2017 at 12:07:20PM +0100, Radosław Pietrzyk wrote:
>> I have and used with stm32 and fb_ili9341. First patch was shitty, my bad.
>>
>
> Could you resend with a patch description which says why you are doing
> this?
>
> "With stm32 and fb_ili9341 the monitor just s
I have and used with stm32 and fb_ili9341. First patch was shitty, my bad.
2017-03-13 12:00 GMT+01:00 Dan Carpenter :
> On Mon, Mar 13, 2017 at 11:28:45AM +0100, Radoslaw Pietrzyk wrote:
>> Allows bpp to be set from dt
>>
>
> Who does this affect in real life? You haven't tested it apparently so
I would expect that VCO clock will force recalculation for all its
children if I am not mistaken.
2016-11-08 17:19 GMT+01:00 Gabriel Fernandez :
> On 11/08/2016 09:52 AM, Radosław Pietrzyk wrote:
>>
>> 2016-11-08 9:35 GMT+01:00 Gabriel Fernandez :
>>>
>>> Hi
2016-11-08 9:35 GMT+01:00 Gabriel Fernandez :
> Hi Radosław
>
> Many thanks for reviewing.
>
> On 11/07/2016 03:57 PM, Radosław Pietrzyk wrote:
>>>
>>> +static struct clk_hw *clk_register_pll_div(const char *name,
>>> + co
> +static struct clk_hw *clk_register_pll_div(const char *name,
> + const char *parent_name, unsigned long flags,
> + void __iomem *reg, u8 shift, u8 width,
> + u8 clk_divider_flags, const struct clk_div_table *table,
> + struct clk_hw *pll_hw
16 matches
Mail list logo
