<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/base/regmap/regmap-irq.c, branch linux-4.16.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.16.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.16.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2017-06-28T19:11:07Z</updated>
<entry>
<title>regmap: irq: add chip option mask_writeonly</title>
<updated>2017-06-28T19:11:07Z</updated>
<author>
<name>Michael Grzeschik</name>
<email>m.grzeschik@pengutronix.de</email>
</author>
<published>2017-06-23T12:35:09Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a71411dbf6c82ba2eb2519717c04ffb19bc4dda5'/>
<id>urn:sha1:a71411dbf6c82ba2eb2519717c04ffb19bc4dda5</id>
<content type='text'>
Some irq controllers have writeonly/multipurpose register layouts. In
those cases we read invalid data back. Here we add the option
mask_writeonly as masking option.

Signed-off-by: Michael Grzeschik &lt;m.grzeschik@pengutronix.de&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: irq: allow to register one cell interrupt controllers</title>
<updated>2017-06-09T17:38:06Z</updated>
<author>
<name>Vladimir Zapolskiy</name>
<email>vladimir_zapolskiy@mentor.com</email>
</author>
<published>2017-06-09T09:05:16Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=63c73b059cbbd96d5161ebe34c533136b4639d26'/>
<id>urn:sha1:63c73b059cbbd96d5161ebe34c533136b4639d26</id>
<content type='text'>
The change makes possible to use regmap-irq interface within drivers
of simple interrupt controllers, which don't have an option to handle
different interrupt types and thus have one cell interrupt controllers
described in device tree bindings.

Signed-off-by: Vladimir Zapolskiy &lt;vladimir_zapolskiy@mentor.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: Fixup the kernel-doc comments on functions/structures</title>
<updated>2017-01-12T17:22:48Z</updated>
<author>
<name>Charles Keepax</name>
<email>ckeepax@opensource.wolfsonmicro.com</email>
</author>
<published>2017-01-12T11:17:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2cf8e2dfdf88363476f23bc600745250b94dbbed'/>
<id>urn:sha1:2cf8e2dfdf88363476f23bc600745250b94dbbed</id>
<content type='text'>
Most of the kernel-doc comments in regmap don't actually generate
correctly. This patch fixes up a few common issues, corrects some typos
and adds some missing argument descriptions.

The most common issues being using a : after the function name which
causes the short description to not render correctly and not separating
the long and short descriptions of the function. There are quite a few
instances of arguments not being described or given the wrong name as
well.

This patch doesn't fixup functions/structures that are currently missing
descriptions.

Signed-off-by: Charles Keepax &lt;ckeepax@opensource.wolfsonmicro.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: irq: Add support to call client specific pre/post interrupt service</title>
<updated>2016-06-02T23:41:15Z</updated>
<author>
<name>Laxman Dewangan</name>
<email>ldewangan@nvidia.com</email>
</author>
<published>2016-05-20T15:10:26Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ccc12561926c0bef9a40865db93b926a0927e93f'/>
<id>urn:sha1:ccc12561926c0bef9a40865db93b926a0927e93f</id>
<content type='text'>
Regmap irq implements the generic interrupt service routine which
is common for most of devices. Some devices, like MAX77620, MAX20024
needs the special handling before and after servicing the interrupt
as generic. For the example, MAX77620 programming guidelines for
interrupt servicing says:
1. When interrupt occurs from PMIC, mask the PMIC interrupt by setting
   GLBLM.
2. Read IRQTOP and service the interrupt accordingly.
3. Once all interrupts has been checked and serviced, the interrupt
   service routine un-masks the hardware interrupt line by clearing
   GLBLM.

The step (2) is implemented in regmap irq as generic routine. For
step (1) and (3), add callbacks from regmap irq to client driver
to handle chip specific configurations.

Signed-off-by: Laxman Dewangan &lt;ldewangan@nvidia.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: irq: Enable irq retriggering for nested irqs</title>
<updated>2016-02-29T14:00:49Z</updated>
<author>
<name>Grygorii Strashko</name>
<email>grygorii.strashko@ti.com</email>
</author>
<published>2016-02-26T15:53:57Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=58a5336292abb032085d621810c3c41c9cea36ed'/>
<id>urn:sha1:58a5336292abb032085d621810c3c41c9cea36ed</id>
<content type='text'>
When nested interrupts are handled with regmap irq framework, we need to
mark the interrupts to be resend for pending interrupts on enable_irq.
Else the events might be lost for nested irqs.

Signed-off-by: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Tested-by: Nishanth Menon &lt;nm@ti.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: irq: add devm apis for regmap_{add,del}_irq_chip</title>
<updated>2016-02-15T19:40:13Z</updated>
<author>
<name>Laxman Dewangan</name>
<email>ldewangan@nvidia.com</email>
</author>
<published>2016-02-10T08:59:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=800c3a0e683601c4ede490e8525852e63b0f6615'/>
<id>urn:sha1:800c3a0e683601c4ede490e8525852e63b0f6615</id>
<content type='text'>
Add device managed APIs for regmap_add_irq_chip() and
regmap_del_irq_chip() so that it can be managed by
device framework for freeing it.

This helps on following:
1. Maintaining the sequence of resource allocation and deallocation
	regmap_add_irq_chip(&amp;d);
	devm_requested_threaded_irq(virq)

	On free path:
		regmap_del_irq_chip(d);
		and then removing the irq registration.

	On this case, regmap irq is deleted before the irq is free.
	This force to use normal irq registration.

	By using devm apis, the sequence can be maintain properly:
		devm_regmap_add_irq_chip(&amp;d);
		devm_requested_threaded_irq(virq);

	and resource deallocation will be done in reverse order
	by device framework.

2. No need to delete the regmap_irq_chip in error path or remove
   callback and hence there is less code on this path.

Signed-off-by: Laxman Dewangan &lt;ldewangan@nvidia.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: irq: dispose all virtual irq before removing domain</title>
<updated>2016-02-09T16:15:19Z</updated>
<author>
<name>Laxman Dewangan</name>
<email>ldewangan@nvidia.com</email>
</author>
<published>2016-02-09T12:28:22Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=46189518d73080f4e4ea269a3b0f4b8583f486bd'/>
<id>urn:sha1:46189518d73080f4e4ea269a3b0f4b8583f486bd</id>
<content type='text'>
It is require to dispose all virtual irq of hwirq on chip
created on given irq domain before removing this irq domain.
Hence dispose all mapped irqs before deleting the irq domains
in regmap_del_irq_chip();

Signed-off-by: Laxman Dewangan &lt;ldewangan@nvidia.com&gt;
Reviewed-by: Javier Martinez Canillas &lt;javier@osg.samsung.com&gt;
Tested-by: Javier Martinez Canillas &lt;javier@osg.samsung.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge remote-tracking branches 'regmap/topic/64bit' and 'regmap/topic/irq-type' into regmap-next</title>
<updated>2016-01-05T19:07:17Z</updated>
<author>
<name>Mark Brown</name>
<email>broonie@kernel.org</email>
</author>
<published>2016-01-05T19:07:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a8d99344c9ebc2f12232473f92beac2f894b6ea5'/>
<id>urn:sha1:a8d99344c9ebc2f12232473f92beac2f894b6ea5</id>
<content type='text'>
</content>
</entry>
<entry>
<title>regmap: irq: add support for configuration of trigger type</title>
<updated>2016-01-05T17:47:18Z</updated>
<author>
<name>Laxman Dewangan</name>
<email>ldewangan@nvidia.com</email>
</author>
<published>2015-12-22T12:55:26Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7a78479fd2acd25db7ecd1744d76f6841ec8a257'/>
<id>urn:sha1:7a78479fd2acd25db7ecd1744d76f6841ec8a257</id>
<content type='text'>
Some of devices supports the trigger level for interrupt
like rising/falling edge specially for GPIOs. The interrupt
support of such devices may have uses the generic regmap irq
framework for implementation.

Add support to configure the trigger type device interrupt
register via regmap-irq framework. The regmap-irq framework
configures the trigger register only if the details of trigger
type registers are provided.

[Fixed use of terery operator for legibility -- broonie]

Signed-off-by: Laxman Dewangan &lt;ldewangan@nvidia.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: replace kmalloc with kmalloc_array</title>
<updated>2015-11-20T12:27:59Z</updated>
<author>
<name>lixiubo</name>
<email>lixiubo@cmss.chinamobile.com</email>
</author>
<published>2015-11-20T10:06:30Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=549e08a0a93442ab62e0aee8aeb8ae6a7f2b5273'/>
<id>urn:sha1:549e08a0a93442ab62e0aee8aeb8ae6a7f2b5273</id>
<content type='text'>
Replace kmalloc with specialized function kmalloc_array when the size
is a multiplication of : number * size

Signed-off-by: lixiubo &lt;lixiubo@cmss.chinamobile.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
</feed>
