diff for duplicates of <1498587929.25567.12.camel@baylibre.com> diff --git a/a/1.txt b/N1/1.txt index 9573294..a644f1f 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -45,12 +45,12 @@ On Tue, 2017-06-27 at 12:49 -0500, Grygorii Strashko wrote: > > The approach is exactly the same as what we trying to follow in the irq > > framework: > > -> > framework?????| irq?????????????????| gpio +> > framework | irq | gpio > > ----------------------------------------------------- -> > index?????????| hwirq???????????????| gpio_num -> > creation??????| irq_create_mapping??| gpio_irq_prepare???? -> > removal???????| irq_dispose_mapping | gpio_irq_unprepare ? -> > (fast) lookup | irq_find_mapping????| gpio_to_irq +> > index | hwirq | gpio_num +> > creation | irq_create_mapping | gpio_irq_prepare ? +> > removal | irq_dispose_mapping | gpio_irq_unprepare ? +> > (fast) lookup | irq_find_mapping | gpio_to_irq > > > > We are going to have at lookup function somehow, why not expose it ? > > @@ -92,26 +92,26 @@ On Tue, 2017-06-27 at 12:49 -0500, Grygorii Strashko wrote: > I'd like to add my 5 cents here :) > 1) "To create the mapping in the gpio_to_irq. Linus, you pointed out that this > is not -> ?allowed as gpio_to_irq is callable in irq context, therefore it should not +> allowed as gpio_to_irq is callable in irq context, therefore it should not > sleep. -> ?Actually 3 drivers [2] are calling gpio_to_irq in irq handlers." +> Actually 3 drivers [2] are calling gpio_to_irq in irq handlers." > > It's not allowed to call gpio_to_irq() from IRQ handlers, as mappings should > already exist at > that time and It might require to do sleepable calls to crate IRQ mappings and -> configure HW.? +> configure HW. > > Drivers, pointed out in first e-mail, should use other APIs in their IRQ > handlers: -> drivers/gpio/gpio-ep93xx.c? +> drivers/gpio/gpio-ep93xx.c > ^ direct call to ep93xx_gpio_to_irq() > * drivers/gpio/gpio-pxa.c -> ?^ use irq_find_mapping() +> ^ use irq_find_mapping() > * drivers/gpio/gpio-tegra.c -> ?^ use irq_find_mapping() +> ^ use irq_find_mapping() > > Also note, IRQ mappings can be created as dynamically (each -> time??gpio_to_irq() is called) +> time gpio_to_irq() is called) Not according to a previous reply from Linus. Right or wrong, it would have made my life a lot easier if it was OK :) @@ -129,7 +129,7 @@ Agreed this is the current situation. I'd like to point you the thread which initially triggered this rfc: https://patchwork.ozlabs.org/patch/684208/ -At the time Linus strongly rejected the idea of calling??irq_create_mapping (or +At the time Linus strongly rejected the idea of calling irq_create_mapping (or any sleeping functions) in gpio_to_irq: please see the reply from Oct 26, 2016 (sorry for quoting such an old discussion but this is really the starting point) @@ -157,7 +157,7 @@ What happens when gpio irq (the pin) is different each time ? and you exhaust the ressource ? It is a corner case, but possible isn't it ? With the gpio char driver -interface??maybe. You would have to reboot to flush the old mappings and +interface maybe. You would have to reboot to flush the old mappings and continue, right ? You could also fail to set the trigger type (which you won't be able to set in diff --git a/a/content_digest b/N1/content_digest index 0038ef8..3e04863 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -6,10 +6,16 @@ "ref\0CACRpkdZ2cqUgMwOFG+9JVyAOxYTfHYa3+yrUzUozLpYD87KdOQ@mail.gmail.com\0" "ref\01498141515.7387.16.camel@baylibre.com\0" "ref\00e12f9bd-4e0b-c602-5627-5dbda5371dee@ti.com\0" - "From\0jbrunet@baylibre.com (Jerome Brunet)\0" - "Subject\0[RFC] gpio: about the need to manage irq mapping dynamically.\0" + "From\0Jerome Brunet <jbrunet@baylibre.com>\0" + "Subject\0Re: [RFC] gpio: about the need to manage irq mapping dynamically.\0" "Date\0Tue, 27 Jun 2017 20:25:29 +0200\0" - "To\0linus-amlogic@lists.infradead.org\0" + "To\0Grygorii Strashko <grygorii.strashko@ti.com>" + " Linus Walleij <linus.walleij@linaro.org>\0" + "Cc\0linux-gpio@vger.kernel.org <linux-gpio@vger.kernel.org>" + Marc Zyngier <marc.zyngier@arm.com> + open list:ARM/Amlogic Meson... <linux-amlogic@lists.infradead.org> + Kevin Hilman <khilman@baylibre.com> + " Linux Kernel <linux-kernel@vger.kernel.org>\0" "\00:1\0" "b\0" "On Tue, 2017-06-27 at 12:49 -0500, Grygorii Strashko wrote:\n" @@ -59,12 +65,12 @@ "> > The approach is exactly the same as what we trying to follow in the irq\n" "> > framework:\n" "> > \n" - "> > framework?????| irq?????????????????| gpio\n" + "> > framework\302\240\302\240\302\240\302\240\302\240| irq\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240| gpio\n" "> > -----------------------------------------------------\n" - "> > index?????????| hwirq???????????????| gpio_num\n" - "> > creation??????| irq_create_mapping??| gpio_irq_prepare????\n" - "> > removal???????| irq_dispose_mapping | gpio_irq_unprepare ?\n" - "> > (fast) lookup | irq_find_mapping????| gpio_to_irq\n" + "> > index\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240| hwirq\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240| gpio_num\n" + "> > creation\302\240\302\240\302\240\302\240\302\240\302\240| irq_create_mapping\302\240\302\240| gpio_irq_prepare\302\240\302\240\302\240?\n" + "> > removal\302\240\302\240\302\240\302\240\302\240\302\240\302\240| irq_dispose_mapping | gpio_irq_unprepare ?\n" + "> > (fast) lookup | irq_find_mapping\302\240\302\240\302\240\302\240| gpio_to_irq\n" "> > \n" "> > We are going to have at lookup function somehow, why not expose it ?\n" "> > \n" @@ -106,26 +112,26 @@ "> I'd like to add my 5 cents here :)\n" "> 1) \"To create the mapping in the gpio_to_irq. Linus, you pointed out that this\n" "> is not\n" - "> ?allowed as gpio_to_irq is callable in irq context, therefore it should not\n" + "> \302\240allowed as gpio_to_irq is callable in irq context, therefore it should not\n" "> sleep.\n" - "> ?Actually 3 drivers [2] are calling gpio_to_irq in irq handlers.\"\n" + "> \302\240Actually 3 drivers [2] are calling gpio_to_irq in irq handlers.\"\n" "> \n" "> It's not allowed to call gpio_to_irq() from IRQ handlers, as mappings should\n" "> already exist at\n" "> that time and It might require to do sleepable calls to crate IRQ mappings and\n" - "> configure HW.?\n" + "> configure HW.\302\240\n" "> \n" "> Drivers, pointed out in first e-mail, should use other APIs in their IRQ\n" "> handlers:\n" - "> drivers/gpio/gpio-ep93xx.c?\n" + "> drivers/gpio/gpio-ep93xx.c\302\240\n" "> ^ direct call to ep93xx_gpio_to_irq()\n" "> * drivers/gpio/gpio-pxa.c\n" - "> ?^ use irq_find_mapping()\n" + "> \302\240^ use irq_find_mapping()\n" "> * drivers/gpio/gpio-tegra.c\n" - "> ?^ use irq_find_mapping()\n" + "> \302\240^ use irq_find_mapping()\n" "> \n" "> Also note, IRQ mappings can be created as dynamically (each\n" - "> time??gpio_to_irq() is called)\n" + "> time\302\240\302\240gpio_to_irq() is called)\n" "\n" "Not according to a previous reply from Linus. Right or wrong, it would have made\n" "my life a lot easier if it was OK :)\n" @@ -143,7 +149,7 @@ "I'd like to point you the thread which initially triggered this rfc:\n" "https://patchwork.ozlabs.org/patch/684208/\n" "\n" - "At the time Linus strongly rejected the idea of calling??irq_create_mapping (or\n" + "At the time Linus strongly rejected the idea of calling\302\240\302\240irq_create_mapping (or\n" "any sleeping functions) in gpio_to_irq: please see the reply from Oct 26, 2016\n" "(sorry for quoting such an old discussion but this is really the starting point)\n" "\n" @@ -171,7 +177,7 @@ "the ressource ?\n" "\n" "It is a corner case, but possible isn't it ? With the gpio char driver\n" - "interface??maybe. You would have to reboot to flush the old mappings and\n" + "interface\302\240\302\240maybe. You would have to reboot to flush the old mappings and\n" "continue, right ? \n" "\n" "You could also fail to set the trigger type (which you won't be able to set in\n" @@ -181,4 +187,4 @@ "Cheers\n" Jerome -4638fad652403ce005e0d60b702997778341ea254eeb38102c948cbe59807f03 +5364bfb279a8d39d8a087e99bd07c99e35615ce2f4d139e93c7cdf9c0150e230
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.