On Fri, May 22, 2015 at 9:35 AM, Joshua Scott
wrote:
> Interrupts were missed if an 8-bit integer overflow occurred. This was
> observed when bank0,pin7 and bank1,pin7 changed simultaniously.
>
> As the 8-bit totals were only checked against zero, replace them with
> booleans. Name the booleans so
Hi Geert,
Thank you for the patch.
On Thursday 21 May 2015 14:05:10 Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven
Acked-by: Laurent Pinchart
> ---
> drivers/pinctrl/nomadik/pinctrl-ab8505.c | 2 +-
> drivers/pinctrl/sh-pfc/pfc-r8a7791.c | 38 ++--
Am 21.05.2015 um 01:04 schrieb Andreas Färber:
> Hi,
>
> Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
>> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin :
>>> When Kernel is executed in place from ROM, the symbol addresses can be
>>> lower than the page offset.
>>>
>>> Tested-by: Chanwoo Choi
>>> Si
* Grygorii Strashko [150522 07:37]:
> Hi Tony,
>
> As I promised in [1] I've prepared a new series for OMAP GPIO driver.
Great!
> Patches 1-2 are bug fixes.
>
> Patches 3-6 is attempt (RFC/RFT) to rework OMAP GPIO driver taking into
> account
> that GPIO Chip and GPIO IRQ Chip functionality
6.165496] Internal error: : 1028 [#1] SMP ARM
[6.170288] Modules linked in:
[6.173522] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.1.0-rc4-next-20150522-00021-g6d8613e #94
[6.182800] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[6.189422] task: c09b0678 ti: c09aa000 ta
Hi,
* Grygorii Strashko [150522 07:37]:
> The omap_gpio_irq_type() can do only configuration of GPIO IRQ
> triggering type, because now OMAP GPIO driver has implemented
> .irq_startup()/.irq_shutdown() which are responsible for
> GPIO bank enabling and pin direction configuration.
>
> Hence, rem
On Thu, 21 May 2015 14:07:50 +0200
Geert Uytterhoeven wrote:
> -It will return an IRQ number, or an negative errno code if the mapping can't
> be
> +It will return an IRQ number, or a negative errno code if the mapping can't
> be
Applied to the docs tree, thanks.
jon
--
To unsubscribe from th
The omap_gpio_irq_type() can do only configuration of GPIO IRQ
triggering type, because now OMAP GPIO driver has implemented
.irq_startup()/.irq_shutdown() which are responsible for
GPIO bank enabling and pin direction configuration.
Hence, remove redundant code and omap_gpio_init_irq() which is
n
The GPIO bank will be kept powered in case if input parameters
are invalid or error occurred in omap_gpio_irq_type.
Hence, fix it by ensuring that GPIO bank will be unpowered
in case of errors and add additional check of value returned
from omap_set_gpio_triggering().
Signed-off-by: Grygorii Stra
Hi Tony,
As I promised in [1] I've prepared a new series for OMAP GPIO driver.
Patches 1-2 are bug fixes.
Patches 3-6 is attempt (RFC/RFT) to rework OMAP GPIO driver taking into account
that GPIO Chip and GPIO IRQ Chip functionality are mostly orthogonal.
Patch 7 is second attempt (RFC/RFT) to
The GPIO Chip and GPIO IRQ Chip functionality are essentially orthogonal,
so GPIO Chip implementation shouldn't touch GPIO IRQ specific registers
and vise versa.
Hence, rework omap_gpio_request:
- don't reset GPIO IRQ triggering type to IRQ_TYPE_NONE, because
GPIO irqchip should be responsible f
The GPIO Chip and GPIO IRQ Chip functionality are essentially orthogonal,
so GPIO IRQ Chip implementation shouldn't touch GPIO specific
registers and vise versa.
Hence, rework omap_gpio_irq_shutdown and try to touch only irqs specific
registers:
- don't configure GPIO as input (it, actually, shoul
Now there are some points related to Runtime PM usage:
1) bank state doesn't need to be checked in places where
Rintime PM is used, bacause Runtime PM maintains its
own usage counter:
if (!BANK_USED(bank))
pm_runtime_get_sync(bank->dev);
so, it's safe to drop such checks.
2) S
The omap_gpio_irq_startup() can be called at time when:
- corresponding GPIO has been requested already and in this case
it has to be configured as input already. If not - return with -EINVAL
and do not try to re-configure it as it could be unsafe.
- corresponding GPIO is free: reconfigure GPIO as
This patch fixes following issue:
- GPIOn is used as IRQ by some dev, for example PCF8575.INT -> gpio6.11
- PCFx driver knows nothing about type of IRQ line (GPIO or not)
so it doesn't request gpio and just do request_irq()
- If gpio6.11 will be exported through the sysfs and then un-xeported
th
On 22/05/15 14:57, Maxime Coquelin wrote:
2015-05-22 15:09 GMT+02:00 Andreas Färber :
As you should know, I did have an RCC clk driver, and there is no such
issue. The two drivers use different mechanisms for initialization. And
I'm pretty sure that I've already remarked that on the list, too.
Am 22.05.2015 um 15:57 schrieb Maxime Coquelin:
> 2015-05-22 15:09 GMT+02:00 Andreas Färber :
>> As you should know, I did have an RCC clk driver, and there is no such
>> issue. The two drivers use different mechanisms for initialization. And
>> I'm pretty sure that I've already remarked that on th
2015-05-22 0:01 GMT+02:00 Andreas Färber :
> Am 21.05.2015 um 21:57 schrieb Maxime Coquelin:
>> Note that for now, I still use your bootloader.
>> I have done the changes to reset the timers in the afboot-stm32.
>> That's the reason why I asked you under which licence it is delivered
>> few months
2015-05-22 15:09 GMT+02:00 Andreas Färber :
> As you should know, I did have an RCC clk driver, and there is no such
> issue. The two drivers use different mechanisms for initialization. And
> I'm pretty sure that I've already remarked that on the list, too.
Yes, you use of_iomap in your clock dri
[...]
>> You are invoking msdc_gate_clock() and msdc_ungate_clock() in a
>> balanced manner, thus hclk_enabled is redundant. Please remove it.
>
> on drv->probe(), already invoke the msdc_ungate_clock(), so, when the
> runtime pm resume invoke the msdc_ungate_clock(), the hclk already
> enabled.
On 22/05/15 13:32, Maxime Coquelin wrote:
2015-05-22 12:07 GMT+02:00 Philipp Zabel :
And that's how I'd expect it to be described by the device tree:
rcc: rcc@40023800 {
compatible = "st,stm32-rcc";
reg = <0x40023800 0xc0>;
};
Doing that, since this register bank
BIOS/platform may use some of the pins by themselves, such as providing SCI
(System Control Interrupt) from the embedded controller. The driver masks
all interrupts at probe time which prevents those pins from triggering
interrupts properly.
Fix this by not masking all interrupts at probe -- it sh
22 matches
Mail list logo
