Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
Hi Jason, On Thursday 12 June 2014 07:35 PM, Jason Cooper wrote: > On Thu, Jun 12, 2014 at 06:57:15AM -0700, Tony Lindgren wrote: >> * Jason Cooper [140612 05:52]: >>> On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote: From: Nishanth Menon When, in the system due to varied reasons, interrupts might be unusable due to hardware behavior, but register maps do exist, then those interrupts should be skipped while mapping irq to crossbars. Signed-off-by: Nishanth Menon Signed-off-by: Sricharan R Signed-off-by: Tony Lindgren >>> >>> Tony, have you applied these somewhere already? >> >> I think some of these I had applied into a branch ready for >> merging but then it was discovered that further changes >> were needed and the branch was dropped. > > Ok. > >> Sricharan, please remove my Signed-off-by from this series. >> If I end up applying it for merging my scripts will add it >> automatically. > > Do you have other changes outside of irqchip depending on this series? > If so, I can set up a topic branch for you guys to base off of. > Otherwise, I'll just apply them to irqchip/core when they're ready. > There are dts changes which are dependent upon this series. http://www.spinics.net/lists/linux-omap/msg108116.html > Also, Sricharan, when you respin this, please clearly identify (in the > comment section) those patches that need to be flagged for stable. It > would be helpful if they were the first patches in the series as well. Ok, i will point this out clearly. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] staging: allow omap4iss to be modular
Hi Tony, On Thursday 12 June 2014 22:30:44 Tony Lindgren wrote: > * Laurent Pinchart [140612 08:32]: > > On Thursday 12 June 2014 08:15:35 Tony Lindgren wrote: > >> * Laurent Pinchart [140612 07:52]: > >>> On Wednesday 11 June 2014 07:47:54 Tony Lindgren wrote: > These should just use either pinctrl-single.c instead for muxing. > Or if they are not mux registers, we do have the syscon mapping > available in omap4.dtsi that pbias-regulator.c is already using. > > Laurent, got any better ideas? > >>> > >>> The ISS driver needs to write a single register, which contains > >>> several independent fields. They thus need to be controlled by a > >>> single driver. Some of them might be considered to be related to > >>> pinmuxing (although I disagree on that), others are certainly not > >>> about muxing (there are clock gate bits for instance). > >>> > >>> Using the syscon mapping seems like the best option. I'll give it a > >>> try. > >> > >> OK if it's not strictly pinctrl related then let's not use > >> pinctrl-single,bits for it. You may be able to implement one or more > >> framework drivers for it for pinctrl/regulator/clock/transceiver > >> whatever that register is doing. > >> > >> In any case it's best to have that handling in a separate helper driver > >> somewhere as it's a separate piece of hardware from the camera module. > >> If it does not fit into any existing frameworks then it's best to have > >> it in a separate driver with the camera driver. > > > > The register contains the following fields that control the two CSI2 PHYs > > (PHY1 and PHY2). > > > > 31CAMERARX_CSI22_LANEENABLE2 PHY2 Lane 2 (CSI22_DX2, CSI22_DY2) > > Enable > > 30CAMERARX_CSI22_LANEENABLE1 PHY2 Lane 1 (CSI22_DX1, CSI22_DY1) > > Enable > > 29CAMERARX_CSI22_LANEENABLE0 PHY2 Lane 0 (CSI22_DX0, CSI22_DY0) > > Enable > > 28CAMERARX_CSI21_LANEENABLE4 PHY1 Lane 4 (CSI21_DX4, CSI21_DY4) > > Enable > > 27CAMERARX_CSI21_LANEENABLE3 PHY1 Lane 3 (CSI21_DX3, CSI21_DY3) > > Enable > > 26CAMERARX_CSI21_LANEENABLE2 PHY1 Lane 2 (CSI21_DX2, CSI21_DY2) > > Enable > > 25CAMERARX_CSI21_LANEENABLE1 PHY1 Lane 1 (CSI21_DX1, CSI21_DY1) > > Enable > > 24CAMERARX_CSI21_LANEENABLE0 PHY1 Lane 0 (CSI21_DX0, CSI21_DY0) > > Enable > > 21CAMERARX_CSI22_CTRLCLKEN PHY2 Clock Enable > > 20:19 CAMERARX_CSI22_CAMMODE PHY2 Mode (CCP2, CSI1, CSI2) > > 18CAMERARX_CSI21_CTRLCLKEN PHY1 Clock Enable > > 17:16 CAMERARX_CSI21_CAMMODE PHY1 Mode (CCP2, CSI1, CSI2) > > > > Bits 18 and 21 could be exposed through CCF. Bits 24 to 31 enable/disable > > the CSI2 lanes, so it could be argued that they could be exposed through > > the pinctrl framework. However, they need to be configured independently, > > possibly at runtime. I'm thus not sure pinctrl would be a good idea. Bits > > 17:16 and 20:19 don't fit in existing frameworks. > > OK thanks for the info. Sounds like drivers/phy might be the right location > for it then and then the phy driver can use the syscon regmap. > > > Given that this register is specific to the ISS, I think handling it as a > > separate device through a separate driver would only complicate the > > implementation without any real benefit. > > Even though it's one register, it shoud still be treated separately from > the camera driver. The problems with keeping the register access to the > control module in the camera driver are at least following: > > 1. They live in separate hardware modules that can be clocked separately Actually I don't think that's true. The CSI2 PHY is part of the camera device, with all its registers but the one above in the camera device register space. For some weird reason a couple of bits were pushed to the control module, but that doesn't make the CSI2 PHY itself a separate device. > 2. Doing a read-back to flush a posted write in one hardware module most >likely won't flush the write to other and that can lead into hard to >find mysterious bugs The OMAP4 ISS driver can just read back the CAMERA_RX register, can't it ? > 3. If we ever have a common system control module driver, we need to >rewrite all the system control module register tinkering in the drivers Sure, but that's already the case today, as the OMAP4 ISS driver already accesses the control module register directly. I won't make that worse :-) > So it's best to try to use an existing framework for it. That avoids tons of > pain later on ;) I agree, but I don't think the PHY framework would be the right abstraction. As explained above the CSI2 PHY is part of the OMAP4 ISS, so modeling its single control module register as a PHY would be a hack. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
Hi Jason,
On Thursday 12 June 2014 07:37 PM, Jason Cooper wrote:
> On Thu, Jun 12, 2014 at 06:49:17PM +0530, Sricharan R wrote:
>> Hi Jason,
>>
>> On Thursday 12 June 2014 06:21 PM, Jason Cooper wrote:
>>> On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote:
From: Nishanth Menon
When, in the system due to varied reasons, interrupts might be unusable
due to hardware behavior, but register maps do exist, then those interrupts
should be skipped while mapping irq to crossbars.
Signed-off-by: Nishanth Menon
Signed-off-by: Sricharan R
Signed-off-by: Tony Lindgren
>>>
>>> Tony, have you applied these somewhere already?
>>>
---
drivers/irqchip/irq-crossbar.c | 47
1 file changed, 43 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c
b/drivers/irqchip/irq-crossbar.c
index 51d4b87..847f6e3 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -13,11 +13,13 @@
#include
#include
#include
+#include
#include
#include
#define IRQ_FREE -1
#define IRQ_RESERVED -2
+#define IRQ_SKIP -3
#define GIC_IRQ_START 32
/*
@@ -34,6 +36,16 @@ struct crossbar_device {
void (*write) (int, int);
};
+/**
+ * struct crossbar_data: Platform specific data
+ * @irqs_unused: array of irqs that cannot be used because of hw erratas
+ * @size: size of the irqs_unused array
+ */
+struct crossbar_data {
+ const uint *irqs_unused;
+ const uint size;
+};
+
static struct crossbar_device *cb;
static inline void crossbar_writel(int irq_no, int cb_no)
@@ -119,10 +131,12 @@ const struct irq_domain_ops routable_irq_domain_ops
= {
.xlate = crossbar_domain_xlate
};
-static int __init crossbar_of_init(struct device_node *node)
+static int __init crossbar_of_init(struct device_node *node,
+ const struct crossbar_data *data)
{
int i, size, max, reserved = 0, entry;
const __be32 *irqsr;
+ const int *irqsk = NULL;
cb = kzalloc(sizeof(*cb), GFP_KERNEL);
@@ -194,6 +208,22 @@ static int __init crossbar_of_init(struct device_node
*node)
reserved += size;
}
+ /* Skip the ones marked as unused */
+ if (data) {
+ irqsk = data->irqs_unused;
+ size = data->size;
+
+ for (i = 0; i < size; i++) {
+ entry = irqsk[i];
+
+ if (entry > max) {
+ pr_err("Invalid skip entry\n");
+ goto err3;
+ }
+ cb->irq_map[entry] = IRQ_SKIP;
+ }
+ }
+
register_routable_domain_ops(&routable_irq_domain_ops);
return 0;
@@ -208,18 +238,27 @@ err1:
return -ENOMEM;
}
+/* irq number 10 cannot be used because of hw bug */
+int dra_irqs_unused[] = { 10 };
+struct crossbar_data cb_dra_data = { dra_irqs_unused,
+ ARRAY_SIZE(dra_irqs_unused) };
+
static const struct of_device_id crossbar_match[] __initconst = {
- { .compatible = "ti,irq-crossbar" },
+ { .compatible = "ti,irq-crossbar", .data = &cb_dra_data },
{}
};
>>>
>>> This is a bug in all implementations of this IP? Or, a specific
>>> SoC's implementation? Would this be better expressed in the dts via a
>>> property? Can we expect future implementations to be fixed?
>>>
>>> thx,
>>>
>>> Jason.
>> Infact this and PATCH#10 should be merged. I will change that.
>>
>> So in Socs's (2 so far) that do have a crossbar, some irqs are mapped
>> through a crossbar and some are directly wired to the irqchip.
>> These 'unused irqs' are those which are directly wired but they still
>> have a crossbar register. Their routing cannot be changed. So this
>> is not really expected usage of the crossbar hw ip. We initially thought
>> having a dts property separately for this, but took this path to avoid
>> loading the dts with additional bindings which may not be generic.
>
> How do you plan to handle future SoCs with this IP and possibly
> different hard-wired irqs?
Yes, that would require adding a new compatible in the above list and dts.
So if adding a new binding in the dts would be cleaner, then i will change
it that way.
Regards,
Sricharan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On Thursday 12 June 2014 07:27 PM, Tony Lindgren wrote: > * Jason Cooper [140612 05:52]: >> On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote: >>> From: Nishanth Menon >>> >>> When, in the system due to varied reasons, interrupts might be unusable >>> due to hardware behavior, but register maps do exist, then those interrupts >>> should be skipped while mapping irq to crossbars. >>> >>> Signed-off-by: Nishanth Menon >>> Signed-off-by: Sricharan R >>> Signed-off-by: Tony Lindgren >> >> Tony, have you applied these somewhere already? > > I think some of these I had applied into a branch ready for > merging but then it was discovered that further changes > were needed and the branch was dropped. > > Sricharan, please remove my Signed-off-by from this series. > If I end up applying it for merging my scripts will add it > automatically. > Ok, will remove it. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 08/19] irqchip: crossbar: fix checkpatch warning
Hi Jason, On Thursday 12 June 2014 09:35 PM, Joe Perches wrote: > On Thu, 2014-06-12 at 11:32 -0400, Jason Cooper wrote: > > Hi Jason. > >>> But bugfix backports haven't been much of an issue in >>> other subsystems with fairly active whitespace/style >>> changes. >> >> Most of the mvebu fixes we've had that failed to apply were generally >> due to a large whitespace change (dts node shuffling, admittedly not >> checkpatch-related). > > So not due to this. > >> I've also frequently been stymied by code cleanups >> when using git blame to find the commit introducing a regression. > > git blame -w can frequently help there. > >> So, my general rule is: If you're submitting a patch to make checkpatch >> be quiet, re-assess the need. If you're making changes and you can fix >> some checkpatch items while you're there, then do so. > > Decent rule. > >> There are certainly legitimate checkpatch-only patches, I just don't >> think this is one qualifies. > > Of course it's the maintainer's choice (and last I saw, > that's you) to ignore whatever doesn't fit the appropriate > vision for the code. > > $ ./scripts/get_maintainer.pl -f drivers/irqchip/irq-crossbar.c > Thomas Gleixner (maintainer:IRQCHIP DRIVERS) > Jason Cooper (maintainer:IRQCHIP DRIVERS) Ok, if this is not qualifying as a separate patch then i will merge this with other patches in the series which touch them. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 05/19] irqchip: crossbar: Change allocation logic by reversing search for free irqs
Hi Jason, On Thursday 12 June 2014 06:26 PM, Jason Cooper wrote: > On Thu, Jun 12, 2014 at 05:23:13PM +0530, Sricharan R wrote: >> From: Nishanth Menon >> >> Reverse the search algorithm to ensure that address mapping and IRQ >> allocation logics are proper. This can open up new bugs which are >> easily fixable rather than wait till allocation logic approaches >> the limit to find new bugs. > > Could you expand on this logic some more? What class of bugs are you > hoping to discover more easily? > class 1. address space errors -> example: reg = ti,max-irqs = is a wrong parameter class 2: irq-reserved list - which decides which entries in the address space is not actually wired in class 3: wrong list of routable-irqs. in general allocating from max to min tends to have benefits in ensuring the different issues that may be present in dts is easily caught at definition time, rather than at a later point in time. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] staging: allow omap4iss to be modular
* Laurent Pinchart [140612 08:32]: > Hi Tony, > > On Thursday 12 June 2014 08:15:35 Tony Lindgren wrote: > > * Laurent Pinchart [140612 07:52]: > > > On Wednesday 11 June 2014 07:47:54 Tony Lindgren wrote: > > > > These should just use either pinctrl-single.c instead for muxing. > > > > Or if they are not mux registers, we do have the syscon mapping > > > > available in omap4.dtsi that pbias-regulator.c is already using. > > > > > > > > Laurent, got any better ideas? > > > > > > The ISS driver needs to write a single register, which contains several > > > independent fields. They thus need to be controlled by a single driver. > > > Some of them might be considered to be related to pinmuxing (although I > > > disagree on that), others are certainly not about muxing (there are clock > > > gate bits for instance). > > > > > > Using the syscon mapping seems like the best option. I'll give it a try. > > > > OK if it's not strictly pinctrl related then let's not use > > pinctrl-single,bits for it. You may be able to implement one or more > > framework drivers for it for pinctrl/regulator/clock/transceiver > > whatever that register is doing. > > > > In any case it's best to have that handling in a separate helper driver > > somewhere as it's a separate piece of hardware from the camera module. > > If it does not fit into any existing frameworks then it's best to have > > it in a separate driver with the camera driver. > > The register contains the following fields that control the two CSI2 PHYs > (PHY1 and PHY2). > > 31CAMERARX_CSI22_LANEENABLE2 PHY2 Lane 2 (CSI22_DX2, CSI22_DY2) Enable > 30CAMERARX_CSI22_LANEENABLE1 PHY2 Lane 1 (CSI22_DX1, CSI22_DY1) Enable > 29CAMERARX_CSI22_LANEENABLE0 PHY2 Lane 0 (CSI22_DX0, CSI22_DY0) Enable > 28CAMERARX_CSI21_LANEENABLE4 PHY1 Lane 4 (CSI21_DX4, CSI21_DY4) Enable > 27CAMERARX_CSI21_LANEENABLE3 PHY1 Lane 3 (CSI21_DX3, CSI21_DY3) Enable > 26CAMERARX_CSI21_LANEENABLE2 PHY1 Lane 2 (CSI21_DX2, CSI21_DY2) Enable > 25CAMERARX_CSI21_LANEENABLE1 PHY1 Lane 1 (CSI21_DX1, CSI21_DY1) Enable > 24CAMERARX_CSI21_LANEENABLE0 PHY1 Lane 0 (CSI21_DX0, CSI21_DY0) Enable > 21CAMERARX_CSI22_CTRLCLKEN PHY2 Clock Enable > 20:19 CAMERARX_CSI22_CAMMODE PHY2 Mode (CCP2, CSI1, CSI2) > 18CAMERARX_CSI21_CTRLCLKEN PHY1 Clock Enable > 17:16 CAMERARX_CSI21_CAMMODE PHY1 Mode (CCP2, CSI1, CSI2) > > Bits 18 and 21 could be exposed through CCF. Bits 24 to 31 enable/disable the > CSI2 lanes, so it could be argued that they could be exposed through the > pinctrl framework. However, they need to be configured independently, > possibly > at runtime. I'm thus not sure pinctrl would be a good idea. Bits 17:16 and > 20:19 don't fit in existing frameworks. OK thanks for the info. Sounds like drivers/phy might be the right location for it then and then the phy driver can use the syscon regmap. > Given that this register is specific to the ISS, I think handling it as a > separate device through a separate driver would only complicate the > implementation without any real benefit. Even though it's one register, it shoud still be treated separately from the camera driver. The problems with keeping the register access to the control module in the camera driver are at least following: 1. They live in separate hardware modules that can be clocked separately 2. Doing a read-back to flush a posted write in one hardware module most likely won't flush the write to other and that can lead into hard to find mysterious bugs 3. If we ever have a common system control module driver, we need to rewrite all the system control module register tinkering in the drivers So it's best to try to use an existing framework for it. That avoids tons of pain later on ;) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/4] ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods
On Thursday 12 June 2014 06:16 PM, Roger Quadros wrote: > Tony, > > Looks like we've missed this for 3.16. Without these SATA support will be broken for DRA7x and OMAP5 so can they be queued for -rc2? Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kedves E-mail felhasználói
Kedves E-mail felhasználói; Túllépte 23432 Repository a postafiók szett Web Szolgáltatások / menedzser, és problémái küldés és fogadó mail míg ellenorzésre. Meg kell frissíteni kattintson az alábbi linkre és töltse ki az adatokat, hogy ellenorizze a számla. Kérjük, kattintson az alábbi linkre, hogy frissítse a tálcát bejegyzést. http://webalert.jigsy.com Figyelem! Ha nem így lesz csak korlátozottan férnek hozzá a postaláda. Ha nem frissíti fiókját számított három napon belül frissítse értesítést, akkor figyelembe kell zárni véglegesen. Tisztelettel, Rendszergazda ® -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Handle non-secure L2C initialization on Exynos4
Hi Russell, On 12.06.2014 18:20, Russell King - ARM Linux wrote: > On Thu, Jun 12, 2014 at 02:38:49PM +0100, Daniel Drake wrote: >> From 2e67231f10ed0b05c2bacfdd05774fe21315d6da Mon Sep 17 00:00:00 2001 >> From: Gu1 >> Date: Mon, 21 Jan 2013 04:13:56 +0100 >> Subject: [PATCH] ARM: EXYNOS: Add secure firmware support for l2x0 init >> >> Conflicts: >> arch/arm/mm/cache-l2x0.c > > For this patch... it's a big NAK because it's taking us right back down > the route of a totally fucked up cache-l2x0.c driver. This is just an old, internal patch that was not going to be upstreamed. I just posted another series yesterday[1], hopefully doing it the right way. Looking forward for review comments. [1] http://thread.gmane.org/gmane.linux.kernel/1722989 > > Why can't you people write stuff properly? There's already another set > of patches on this mailing list which want to pass the virtual base > address of the l2x0 controller to l2c_write_sec() so that various > registers can be read back, because the platform's secure API can > only update several registers at the same time. Probably the series you mention is [1]? :) > > This is the same pattern that is revealed in this patch. So, what > this means is that the l2c_write_sec API is wrong. We need to come > up with a *replacement* API which allows the platforms to do this > kind of setup in a *clean* way, and stop creating rotten hacks like > this which just makes long term maintanence a nightmare. > > So... please start doing stuff properly. If you don't, you're going > to be getting more flames from me, especially if you start doing this > kind of hackery on code that I've been cleaning up to get rid of such > crap. > Yes, I fully agree. Fortunately that was not supposed to hit upstream. You've done a lot of great work to refactor this driver (thanks!), which made it possible to support Exynos secure firmware in a sane way and this is how it should be done. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Handle non-secure L2C initialization on Exynos4
On Thu, Jun 12, 2014 at 02:38:49PM +0100, Daniel Drake wrote: > From 2e67231f10ed0b05c2bacfdd05774fe21315d6da Mon Sep 17 00:00:00 2001 > From: Gu1 > Date: Mon, 21 Jan 2013 04:13:56 +0100 > Subject: [PATCH] ARM: EXYNOS: Add secure firmware support for l2x0 init > > Conflicts: > arch/arm/mm/cache-l2x0.c For this patch... it's a big NAK because it's taking us right back down the route of a totally fucked up cache-l2x0.c driver. Why can't you people write stuff properly? There's already another set of patches on this mailing list which want to pass the virtual base address of the l2x0 controller to l2c_write_sec() so that various registers can be read back, because the platform's secure API can only update several registers at the same time. This is the same pattern that is revealed in this patch. So, what this means is that the l2c_write_sec API is wrong. We need to come up with a *replacement* API which allows the platforms to do this kind of setup in a *clean* way, and stop creating rotten hacks like this which just makes long term maintanence a nightmare. So... please start doing stuff properly. If you don't, you're going to be getting more flames from me, especially if you start doing this kind of hackery on code that I've been cleaning up to get rid of such crap. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 08/19] irqchip: crossbar: fix checkpatch warning
On Thu, 2014-06-12 at 11:32 -0400, Jason Cooper wrote: Hi Jason. > > But bugfix backports haven't been much of an issue in > > other subsystems with fairly active whitespace/style > > changes. > > Most of the mvebu fixes we've had that failed to apply were generally > due to a large whitespace change (dts node shuffling, admittedly not > checkpatch-related). So not due to this. > I've also frequently been stymied by code cleanups > when using git blame to find the commit introducing a regression. git blame -w can frequently help there. > So, my general rule is: If you're submitting a patch to make checkpatch > be quiet, re-assess the need. If you're making changes and you can fix > some checkpatch items while you're there, then do so. Decent rule. > There are certainly legitimate checkpatch-only patches, I just don't > think this is one qualifies. Of course it's the maintainer's choice (and last I saw, that's you) to ignore whatever doesn't fit the appropriate vision for the code. $ ./scripts/get_maintainer.pl -f drivers/irqchip/irq-crossbar.c Thomas Gleixner (maintainer:IRQCHIP DRIVERS) Jason Cooper (maintainer:IRQCHIP DRIVERS) ... cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/2] clk: of: introduce of_clk_get_from_set()
In many case it's useful to divide device's clocks into
few sets according to their designation.
- some clocks can be optional for the device
- some clocks can be managed by PM frameworks (like clock_ops for example)
while some need to be managed by driver directly.
This patch introduces new API of_clk_get_from_set() which allows
the callers to specify additional prefix to be used together with
generic DT clocks list property name "clocks".
In the example bellow, the caller asks CLK framework to retrieve
clock from the clocks list "clkops-clocks" and not from "clocks":
DT:
usb: usb@268 {
compatible = "ti,keystone-dwc3";
[...]
clkops-clocks = <&clkusb>;
Code:
clk = of_clk_get_from_set(np, "clkops", 0);
This changes will not affect on already existed code.
Signed-off-by: Grygorii Strashko
---
drivers/clk/clkdev.c | 24 ++--
include/linux/clk.h |7 +++
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index f890b90..2308518 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -53,7 +53,8 @@ struct clk *of_clk_get_by_clkspec(struct of_phandle_args
*clkspec)
return clk;
}
-struct clk *of_clk_get(struct device_node *np, int index)
+static struct clk *of_clk_get_named(struct device_node *np,
+ const char *propname, int index)
{
struct of_phandle_args clkspec;
struct clk *clk;
@@ -62,7 +63,7 @@ struct clk *of_clk_get(struct device_node *np, int index)
if (index < 0)
return ERR_PTR(-EINVAL);
- rc = of_parse_phandle_with_args(np, "clocks", "#clock-cells", index,
+ rc = of_parse_phandle_with_args(np, propname, "#clock-cells", index,
&clkspec);
if (rc)
return ERR_PTR(rc);
@@ -71,8 +72,27 @@ struct clk *of_clk_get(struct device_node *np, int index)
of_node_put(clkspec.np);
return clk;
}
+
+struct clk *of_clk_get(struct device_node *np, int index)
+{
+ return of_clk_get_named(np, "clocks", index);
+}
EXPORT_SYMBOL(of_clk_get);
+struct clk *of_clk_get_from_set(struct device_node *np,
+ const char *set_id, int index)
+{
+ char prop_name[32]; /* 32 is max size of property name */
+
+ if (set_id)
+ snprintf(prop_name, 32, "%s-clocks", set_id);
+ else
+ snprintf(prop_name, 32, "clocks");
+
+ return of_clk_get_named(np, prop_name, index);
+}
+EXPORT_SYMBOL(of_clk_get_from_set);
+
/**
* of_clk_get_by_name() - Parse and lookup a clock referenced by a device node
* @np: pointer to clock consumer node
diff --git a/include/linux/clk.h b/include/linux/clk.h
index fb5e097..fc8865a 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -397,6 +397,8 @@ struct of_phandle_args;
#if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
struct clk *of_clk_get(struct device_node *np, int index);
+struct clk *of_clk_get_from_set(struct device_node *np,
+ const char *set_id, int index);
struct clk *of_clk_get_by_name(struct device_node *np, const char *name);
struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec);
#else
@@ -409,6 +411,11 @@ static inline struct clk *of_clk_get_by_name(struct
device_node *np,
{
return ERR_PTR(-ENOENT);
}
+static inline struct clk *of_clk_get_from_set(struct device_node *np,
+ const char *set_id, int index)
+{
+ return ERR_PTR(-ENOENT);
+}
#endif
#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/2] use named clocks list to register clocks for PM clock domain
Hi Geert,
I've spent some time testing your patches on Keystone 2 SoC as I am interested
in these patches.
The Keystone 2 is pure DT platform, but we reuse some Drivers from Davinci SoC.
Now I have to dial with following problem:
- Some modules on Keystone need more then one clock to be managed by PM clock.
As result, I can solve this by filling cond_id list in structure
pm_clk_notifier_block.
For example:
static struct pm_clk_notifier_block platform_domain_notifier = {
.pm_domain = &keystone_pm_domain,
.con_ids = { "fck", "master", "slave", NULL },
};
But, in this case I'll need to add names for all clocks or rename existed
clock's names in DT to be compatible with above list, like:
clock-names = "gpio"; -> clock-names = "fck";
- or -
clocks = <&clkspi>;
+ clock-names = "fck";
Your series gracefully solves this problem for me, but I'd like to avoid
to use new CLK flag CLK_RUNTIME_PM, because:
- The same driver is used for all gated clocks for Keystone (and probably for
other SoCs)
- Some gated clocks can be optional.
Taking into account above, driver for gated clock will need to maintain
additional
information internally about clocks which are suitable for Runtime PM -
it is too hard to support :(.
Therefore, I propose a solution which allows to specify clocks suitable for
Runtime PM in DT using special property "clkops-clocks" (name can be changed:).
Another possible option is to use DT definition like this:
spi2: spi@21000800 {
compatible = "ti,dm6441-spi";
reg = <0x21000800 0x200>;
num-cs = <4>;
ti,davinci-spi-intr-line = <0>;
interrupts = ;
-> clkops-clocks {
-> clocks = <&clkspi>;
-> }
}
Regarding supporting of EPROBE_DEFER, in my opinion simplest solution would be
to
call of_clk_register_runtime_pm_clocks() directly from drivers.
Another option 1, call of_clk_register_runtime_pm_clocks() before driver's
probing
seems will be banned by Greg and Rafael.
Another option 2, continue to use Bus notifiers, but then error path need to be
handled somehow. Now BUS_NOTIFY_BIND_DRIVER even is sent before probing, but
it seems that nothing is sent in case if probe was failed.
Grygorii Strashko (2):
clk: of: introduce of_clk_get_from_set()
of/clk: use "clkops-clocks" to specify clocks handled by clock_ops
domain
drivers/clk/clkdev.c | 24 ++--
drivers/of/of_clk.c |7 ++-
include/linux/clk.h |7 +++
3 files changed, 31 insertions(+), 7 deletions(-)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 2/2] of/clk: use "clkops-clocks" to specify clocks handled by clock_ops domain
Use "clkops-clocks" property to specify clocks handled by
clock_ops domain PM domain. Only clocks defined in "clkops-clocks"
set of clocks will be handled by Runtime PM through clock_ops
Pm domain.
Signed-off-by: Grygorii Strashko
---
drivers/of/of_clk.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/of/of_clk.c b/drivers/of/of_clk.c
index 35f5e9f..5f9b90e 100644
--- a/drivers/of/of_clk.c
+++ b/drivers/of/of_clk.c
@@ -86,11 +86,8 @@ int of_clk_register_runtime_pm_clocks(struct device_node *np,
struct clk *clk;
int error;
- for (i = 0; (clk = of_clk_get(np, i)) && !IS_ERR(clk); i++) {
- if (!clk_may_runtime_pm(clk)) {
- clk_put(clk);
- continue;
- }
+ for (i = 0; (clk = of_clk_get_from_set(np, "clkops", i)) &&
+!IS_ERR(clk); i++) {
error = of_clk_register(dev, clk);
if (error) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] staging: allow omap4iss to be modular
On Thu, Jun 12, 2014 at 04:28:39PM +0200, Arnd Bergmann wrote: > On Thursday 12 June 2014 07:25:15 Greg KH wrote: > > On Thu, Jun 12, 2014 at 04:15:32PM +0200, Arnd Bergmann wrote: > > > On Thursday 12 June 2014 16:12:17 Laurent Pinchart wrote: > > > > > From 3a965f4fd5a6b3ef4a66aa4e7c916cfd34fd5706 Mon Sep 17 00:00:00 2001 > > > > > From: Arnd Bergmann > > > > > Date: Tue, 21 Jan 2014 09:32:43 +0100 > > > > > Subject: [PATCH] [media] staging: tighten omap4iss dependencies > > > > > > > > > > The OMAP4 camera support depends on I2C and VIDEO_V4L2, both > > > > > of which can be loadable modules. This causes build failures > > > > > if we want the camera driver to be built-in. > > > > > > > > > > This can be solved by turning the option into "tristate", > > > > > which unfortunately causes another problem, because the > > > > > driver incorrectly calls a platform-internal interface > > > > > for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel. > > > > > > > > > > Instead, this patch just forbids the invalid configurations > > > > > and ensures that the driver can only be built if all its > > > > > dependencies are built-in. > > > > > > > > > > Signed-off-by: Arnd Bergmann > > > > > > > > Acked-by: Laurent Pinchart > > > > > > > > Should I take this in my tree for v3.17 or would you like to fast-track > > > > it ? > > > > > > > > > > I'd actually like to see it in 3.15 as a stable backport if possible, > > > > It's not stable material, sorry. > > To clarify, I was talking about second version of the patch, > not the original one. It just does this: > > > config VIDEO_OMAP4 > > bool "OMAP 4 Camera support" > > - depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4 > > + depends on VIDEO_V4L2=y && VIDEO_V4L2_SUBDEV_API && I2C=y && > > ARCH_OMAP4 > > select VIDEOBUF2_DMA_CONTIG > > ---help--- > > Driver for an OMAP 4 ISS controller. > > which enforces that configurations that cannot be compiled > will not be selectable in Kconfig, so we can have allmodconfig > working. I thought that was ok for -stable. Ah, yes, that one works, sorry, I was thinking of the first one. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 08/19] irqchip: crossbar: fix checkpatch warning
Hey Joe,
On Thu, Jun 12, 2014 at 07:18:31AM -0700, Joe Perches wrote:
> On Thu, 2014-06-12 at 19:05 +0530, Sricharan R wrote:
> > On Thursday 12 June 2014 06:40 PM, Jason Cooper wrote:
> > > On Thu, Jun 12, 2014 at 05:23:16PM +0530, Sricharan R wrote:
> > >> diff --git a/drivers/irqchip/irq-crossbar.c
> > >> b/drivers/irqchip/irq-crossbar.c
> []
> > >> @@ -34,7 +34,8 @@ struct crossbar_device {
> > >> uint *irq_map;
> > >> void __iomem *crossbar_base;
> > >> int *register_offsets;
> > >> -void (*write) (int, int);
> > >> +
> > >> +void (*write)(int, int);
> > >
> > > The empty line here looks bogus to me.
>
> Good eye. It's unnecessary.
>
> > > Did you re-run checkpatch after fixing the unnecessary space to
> > > see if it still complained about having a 'blank line after
> > > declarations'?
> > >
> > Yes, it still complains even after fixing unnecessary space.
>
> It's a checkpatch defect.
>
> It's been fixed by:
> https://lkml.org/lkml/2014/6/6/426
Ah, good to know.
> > > I'm generally opposed to these sorts of checkpatch patches, especially
> > > when they are just warnings. It's great for a new driver in the staging
> > > tree, but it makes backporting future bugfixes that much harder when
> > > drivers have been live in mainline.
>
> Blind adherence to checkpatch isn't always a great idea.
Agreed.
> But bugfix backports haven't been much of an issue in
> other subsystems with fairly active whitespace/style
> changes.
Most of the mvebu fixes we've had that failed to apply were generally
due to a large whitespace change (dts node shuffling, admittedly not
checkpatch-related). I've also frequently been stymied by code cleanups
when using git blame to find the commit introducing a regression.
So, my general rule is: If you're submitting a patch to make checkpatch
be quiet, re-assess the need. If you're making changes and you can fix
some checkpatch items while you're there, then do so.
There are certainly legitimate checkpatch-only patches, I just don't
think this is one qualifies.
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] staging: allow omap4iss to be modular
Hi Tony, On Thursday 12 June 2014 08:15:35 Tony Lindgren wrote: > * Laurent Pinchart [140612 07:52]: > > On Wednesday 11 June 2014 07:47:54 Tony Lindgren wrote: > > > These should just use either pinctrl-single.c instead for muxing. > > > Or if they are not mux registers, we do have the syscon mapping > > > available in omap4.dtsi that pbias-regulator.c is already using. > > > > > > Laurent, got any better ideas? > > > > The ISS driver needs to write a single register, which contains several > > independent fields. They thus need to be controlled by a single driver. > > Some of them might be considered to be related to pinmuxing (although I > > disagree on that), others are certainly not about muxing (there are clock > > gate bits for instance). > > > > Using the syscon mapping seems like the best option. I'll give it a try. > > OK if it's not strictly pinctrl related then let's not use > pinctrl-single,bits for it. You may be able to implement one or more > framework drivers for it for pinctrl/regulator/clock/transceiver > whatever that register is doing. > > In any case it's best to have that handling in a separate helper driver > somewhere as it's a separate piece of hardware from the camera module. > If it does not fit into any existing frameworks then it's best to have > it in a separate driver with the camera driver. The register contains the following fields that control the two CSI2 PHYs (PHY1 and PHY2). 31CAMERARX_CSI22_LANEENABLE2 PHY2 Lane 2 (CSI22_DX2, CSI22_DY2) Enable 30CAMERARX_CSI22_LANEENABLE1 PHY2 Lane 1 (CSI22_DX1, CSI22_DY1) Enable 29CAMERARX_CSI22_LANEENABLE0 PHY2 Lane 0 (CSI22_DX0, CSI22_DY0) Enable 28CAMERARX_CSI21_LANEENABLE4 PHY1 Lane 4 (CSI21_DX4, CSI21_DY4) Enable 27CAMERARX_CSI21_LANEENABLE3 PHY1 Lane 3 (CSI21_DX3, CSI21_DY3) Enable 26CAMERARX_CSI21_LANEENABLE2 PHY1 Lane 2 (CSI21_DX2, CSI21_DY2) Enable 25CAMERARX_CSI21_LANEENABLE1 PHY1 Lane 1 (CSI21_DX1, CSI21_DY1) Enable 24CAMERARX_CSI21_LANEENABLE0 PHY1 Lane 0 (CSI21_DX0, CSI21_DY0) Enable 21CAMERARX_CSI22_CTRLCLKEN PHY2 Clock Enable 20:19 CAMERARX_CSI22_CAMMODE PHY2 Mode (CCP2, CSI1, CSI2) 18CAMERARX_CSI21_CTRLCLKEN PHY1 Clock Enable 17:16 CAMERARX_CSI21_CAMMODE PHY1 Mode (CCP2, CSI1, CSI2) Bits 18 and 21 could be exposed through CCF. Bits 24 to 31 enable/disable the CSI2 lanes, so it could be argued that they could be exposed through the pinctrl framework. However, they need to be configured independently, possibly at runtime. I'm thus not sure pinctrl would be a good idea. Bits 17:16 and 20:19 don't fit in existing frameworks. Given that this register is specific to the ISS, I think handling it as a separate device through a separate driver would only complicate the implementation without any real benefit. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] staging: allow omap4iss to be modular
* Laurent Pinchart [140612 07:52]: > On Wednesday 11 June 2014 07:47:54 Tony Lindgren wrote: > > > > These should just use either pinctrl-single.c instead for muxing. > > Or if they are not mux registers, we do have the syscon mapping > > available in omap4.dtsi that pbias-regulator.c is already using. > > > > Laurent, got any better ideas? > > The ISS driver needs to write a single register, which contains several > independent fields. They thus need to be controlled by a single driver. Some > of them might be considered to be related to pinmuxing (although I disagree > on > that), others are certainly not about muxing (there are clock gate bits for > instance). > > Using the syscon mapping seems like the best option. I'll give it a try. OK if it's not strictly pinctrl related then let's not use pinctrl-single,bits for it. You may be able to implement one or more framework drivers for it for pinctrl/regulator/clock/transceiver whatever that register is doing. In any case it's best to have that handling in a separate helper driver somewhere as it's a separate piece of hardware from the camera module. If it does not fit into any existing frameworks then it's best to have it in a separate driver with the camera driver. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] staging: allow omap4iss to be modular
Hi Arnd, On Thursday 12 June 2014 16:28:39 Arnd Bergmann wrote: > On Thursday 12 June 2014 07:25:15 Greg KH wrote: > > On Thu, Jun 12, 2014 at 04:15:32PM +0200, Arnd Bergmann wrote: > > > On Thursday 12 June 2014 16:12:17 Laurent Pinchart wrote: > > > > > From 3a965f4fd5a6b3ef4a66aa4e7c916cfd34fd5706 Mon Sep 17 00:00:00 > > > > > 2001 > > > > > From: Arnd Bergmann > > > > > Date: Tue, 21 Jan 2014 09:32:43 +0100 > > > > > Subject: [PATCH] [media] staging: tighten omap4iss dependencies > > > > > > > > > > The OMAP4 camera support depends on I2C and VIDEO_V4L2, both > > > > > of which can be loadable modules. This causes build failures > > > > > if we want the camera driver to be built-in. > > > > > > > > > > This can be solved by turning the option into "tristate", > > > > > which unfortunately causes another problem, because the > > > > > driver incorrectly calls a platform-internal interface > > > > > for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel. > > > > > > > > > > Instead, this patch just forbids the invalid configurations > > > > > and ensures that the driver can only be built if all its > > > > > dependencies are built-in. > > > > > > > > > > Signed-off-by: Arnd Bergmann > > > > > > > > Acked-by: Laurent Pinchart > > > > > > > > Should I take this in my tree for v3.17 or would you like to > > > > fast-track it ?> > > > > I'd actually like to see it in 3.15 as a stable backport if possible, > > > > It's not stable material, sorry. > > To clarify, I was talking about second version of the patch, > not the original one. It just does this: > > > config VIDEO_OMAP4 > > bool "OMAP 4 Camera support" > > - depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4 > > + depends on VIDEO_V4L2=y && VIDEO_V4L2_SUBDEV_API && I2C=y && > > ARCH_OMAP4 > > select VIDEOBUF2_DMA_CONTIG > > ---help--- > > Driver for an OMAP 4 ISS controller. > > which enforces that configurations that cannot be compiled > will not be selectable in Kconfig, so we can have allmodconfig > working. I thought that was ok for -stable. > > > > but definitely in 3.16. What is the normal path for staging/media > > > but fix patches? > > > > Through Mauro's tree. > > Ok. I've applied the patch to my tree and will send a pull request to Mauro for v3.16 as soon as you reach an agreement with Greg on whether I should add CC: stable or not. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] staging: allow omap4iss to be modular
Hi Tony,
On Wednesday 11 June 2014 07:47:54 Tony Lindgren wrote:
> * Arnd Bergmann [140611 07:37]:
> > The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
> > of which can be loadable modules. This causes build failures
> > if we want the camera driver to be built-in.
>
> That's good news, but let's not fix it this way.
>
> > This can be solved by turning the option into "tristate",
> > which unfortunately causes another problem, because the
> > driver incorrectly calls a platform-internal interface
> > for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
> > To work around that, we can export those symbols, but
> > that isn't really the correct solution, as we should not
> > have dependencies on platform code this way.
> >
> > Signed-off-by: Arnd Bergmann
> > ---
> > This is one of just two patches we currently need to get
> > 'make allmodconfig' to build again on ARM.
> >
> > diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
> > index 751f354..05d2d98 100644
> > --- a/arch/arm/mach-omap2/control.c
> > +++ b/arch/arm/mach-omap2/control.c
> > @@ -190,11 +190,13 @@ u32 omap4_ctrl_pad_readl(u16 offset)
> > {
> > return readl_relaxed(OMAP4_CTRL_PAD_REGADDR(offset));
> > }
> > +EXPORT_SYMBOL_GPL(omap4_ctrl_pad_readl);
> >
> > void omap4_ctrl_pad_writel(u32 val, u16 offset)
> > {
> > writel_relaxed(val, OMAP4_CTRL_PAD_REGADDR(offset));
> > }
> > +EXPORT_SYMBOL_GPL(omap4_ctrl_pad_writel);
> >
> > #ifdef CONFIG_ARCH_OMAP3
>
> Exporting these will likely cause immediate misuse in other
> drivers all over the place.
>
> These should just use either pinctrl-single.c instead for muxing.
> Or if they are not mux registers, we do have the syscon mapping
> available in omap4.dtsi that pbias-regulator.c is already using.
>
> Laurent, got any better ideas?
The ISS driver needs to write a single register, which contains several
independent fields. They thus need to be controlled by a single driver. Some
of them might be considered to be related to pinmuxing (although I disagree on
that), others are certainly not about muxing (there are clock gate bits for
instance).
Using the syscon mapping seems like the best option. I'll give it a try.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] staging: allow omap4iss to be modular
On Thursday 12 June 2014 07:25:15 Greg KH wrote: > On Thu, Jun 12, 2014 at 04:15:32PM +0200, Arnd Bergmann wrote: > > On Thursday 12 June 2014 16:12:17 Laurent Pinchart wrote: > > > > From 3a965f4fd5a6b3ef4a66aa4e7c916cfd34fd5706 Mon Sep 17 00:00:00 2001 > > > > From: Arnd Bergmann > > > > Date: Tue, 21 Jan 2014 09:32:43 +0100 > > > > Subject: [PATCH] [media] staging: tighten omap4iss dependencies > > > > > > > > The OMAP4 camera support depends on I2C and VIDEO_V4L2, both > > > > of which can be loadable modules. This causes build failures > > > > if we want the camera driver to be built-in. > > > > > > > > This can be solved by turning the option into "tristate", > > > > which unfortunately causes another problem, because the > > > > driver incorrectly calls a platform-internal interface > > > > for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel. > > > > > > > > Instead, this patch just forbids the invalid configurations > > > > and ensures that the driver can only be built if all its > > > > dependencies are built-in. > > > > > > > > Signed-off-by: Arnd Bergmann > > > > > > Acked-by: Laurent Pinchart > > > > > > Should I take this in my tree for v3.17 or would you like to fast-track > > > it ? > > > > > > > I'd actually like to see it in 3.15 as a stable backport if possible, > > It's not stable material, sorry. To clarify, I was talking about second version of the patch, not the original one. It just does this: > config VIDEO_OMAP4 > bool "OMAP 4 Camera support" > - depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4 > + depends on VIDEO_V4L2=y && VIDEO_V4L2_SUBDEV_API && I2C=y && ARCH_OMAP4 > select VIDEOBUF2_DMA_CONTIG > ---help--- > Driver for an OMAP 4 ISS controller. which enforces that configurations that cannot be compiled will not be selectable in Kconfig, so we can have allmodconfig working. I thought that was ok for -stable. > > but definitely in 3.16. What is the normal path for staging/media > > but fix patches? > > Through Mauro's tree. Ok. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 08/19] irqchip: crossbar: fix checkpatch warning
On Thu, 2014-06-12 at 19:05 +0530, Sricharan R wrote:
> On Thursday 12 June 2014 06:40 PM, Jason Cooper wrote:
> > On Thu, Jun 12, 2014 at 05:23:16PM +0530, Sricharan R wrote:
> >> diff --git a/drivers/irqchip/irq-crossbar.c
> >> b/drivers/irqchip/irq-crossbar.c
[]
> >> @@ -34,7 +34,8 @@ struct crossbar_device {
> >>uint *irq_map;
> >>void __iomem *crossbar_base;
> >>int *register_offsets;
> >> - void (*write) (int, int);
> >> +
> >> + void (*write)(int, int);
> >
> > The empty line here looks bogus to me.
Good eye. It's unnecessary.
> Did you re-run checkpatch after
> > fixing the unnecessary space to see if it still complained about having
> > a 'blank line after declarations'?
> >
> Yes, it still complains even after fixing unnecessary space.
It's a checkpatch defect.
It's been fixed by:
https://lkml.org/lkml/2014/6/6/426
> > I'm generally opposed to these sorts of checkpatch patches, especially
> > when they are just warnings. It's great for a new driver in the staging
> > tree, but it makes backporting future bugfixes that much harder when
> > drivers have been live in mainline.
Blind adherence to checkpatch isn't always a great idea.
But bugfix backports haven't been much of an issue in
other subsystems with fairly active whitespace/style
changes.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] staging: allow omap4iss to be modular
On Thu, Jun 12, 2014 at 04:15:32PM +0200, Arnd Bergmann wrote: > On Thursday 12 June 2014 16:12:17 Laurent Pinchart wrote: > > > From 3a965f4fd5a6b3ef4a66aa4e7c916cfd34fd5706 Mon Sep 17 00:00:00 2001 > > > From: Arnd Bergmann > > > Date: Tue, 21 Jan 2014 09:32:43 +0100 > > > Subject: [PATCH] [media] staging: tighten omap4iss dependencies > > > > > > The OMAP4 camera support depends on I2C and VIDEO_V4L2, both > > > of which can be loadable modules. This causes build failures > > > if we want the camera driver to be built-in. > > > > > > This can be solved by turning the option into "tristate", > > > which unfortunately causes another problem, because the > > > driver incorrectly calls a platform-internal interface > > > for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel. > > > > > > Instead, this patch just forbids the invalid configurations > > > and ensures that the driver can only be built if all its > > > dependencies are built-in. > > > > > > Signed-off-by: Arnd Bergmann > > > > Acked-by: Laurent Pinchart > > > > Should I take this in my tree for v3.17 or would you like to fast-track it ? > > > > I'd actually like to see it in 3.15 as a stable backport if possible, It's not stable material, sorry. > but definitely in 3.16. What is the normal path for staging/media > but fix patches? Through Mauro's tree. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] staging: allow omap4iss to be modular
On Thursday 12 June 2014 16:12:17 Laurent Pinchart wrote: > > From 3a965f4fd5a6b3ef4a66aa4e7c916cfd34fd5706 Mon Sep 17 00:00:00 2001 > > From: Arnd Bergmann > > Date: Tue, 21 Jan 2014 09:32:43 +0100 > > Subject: [PATCH] [media] staging: tighten omap4iss dependencies > > > > The OMAP4 camera support depends on I2C and VIDEO_V4L2, both > > of which can be loadable modules. This causes build failures > > if we want the camera driver to be built-in. > > > > This can be solved by turning the option into "tristate", > > which unfortunately causes another problem, because the > > driver incorrectly calls a platform-internal interface > > for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel. > > > > Instead, this patch just forbids the invalid configurations > > and ensures that the driver can only be built if all its > > dependencies are built-in. > > > > Signed-off-by: Arnd Bergmann > > Acked-by: Laurent Pinchart > > Should I take this in my tree for v3.17 or would you like to fast-track it ? > I'd actually like to see it in 3.15 as a stable backport if possible, but definitely in 3.16. What is the normal path for staging/media but fix patches? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Handle non-secure L2C initialization on Exynos4
Hi Daniel, On 12.06.2014 15:38, Daniel Drake wrote: > Hi Tomasz, > > Thanks for working on this! > > I have just tried this, against Linus master > 64b2d1fbbfda07765dae3f601862796a61b2c451. > Added patch "ARM: dts: Initial ODROID U2 support" and booted on > ODROID-U2. I believe this board has the security enabled. > > Unfortunately, it hangs during early boot. With earlyprintk the last > messages seen are: > > L2C: platform modifies aux control register: 0x0207 -> 0x3e470001 > L2C: platform provided aux values permit register corruption. > L2C: DT/platform modifies aux control register: 0x0207 -> 0x3e470001 > L2C-310 enabling early BRESP for Cortex-A9 > L2C-310: enabling full line of zeros but not enabled in Cortex-A9 > L2C-310 ID prefetch enabled, offset 1 lines > L2C-310 dynamic clock gating enabled, standby mode enabled > L2C-310 cache controller enabled, 16 ways, 1024 kB > L2C-310: CACHE_ID 0x4100c4c8, AUX_CTRL 0x7e470001 > Thanks for testing. We have some ODROIDs U2 and U3 here too so I'll try to reproduce and investigate the issue. > I then tried to go back to the earlier patch "ARM: EXYNOS: Add secure > firmware support for l2x0 init" (attached, needed a rebase) but that > one also now hangs at: > > L2C: platform modifies aux control register: 0x0207 -> 0x3e470001 > > It did work on 3.14 though. Looking at the changelogs, many changes > have been made to l2x0 recently. Can you confirm that you have tested > your patches against a kernel with all of Russell King's recent > changes? I'm usually working on latest linux-next, so I'm pretty sure all the mentioned patches were already in my tree. The base for this series was next-20140610 tag of linux-next tree. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] staging: allow omap4iss to be modular
Hi Arnd,
On Wednesday 11 June 2014 16:49:31 Arnd Bergmann wrote:
> On Wednesday 11 June 2014 09:42:04 Nishanth Menon wrote:
> > On 06/11/2014 09:35 AM, Arnd Bergmann wrote:
> > > The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
> > > of which can be loadable modules. This causes build failures
> > > if we want the camera driver to be built-in.
> > >
> > > This can be solved by turning the option into "tristate",
> > > which unfortunately causes another problem, because the
> > > driver incorrectly calls a platform-internal interface
> > > for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
> > > To work around that, we can export those symbols, but
> > > that isn't really the correct solution, as we should not
> > > have dependencies on platform code this way.
> > >
> > > Signed-off-by: Arnd Bergmann
> > > ---
> > > This is one of just two patches we currently need to get
> > > 'make allmodconfig' to build again on ARM.
> > >
> > > diff --git a/arch/arm/mach-omap2/control.c
> > > b/arch/arm/mach-omap2/control.c
> > > index 751f354..05d2d98 100644
> > > --- a/arch/arm/mach-omap2/control.c
> > > +++ b/arch/arm/mach-omap2/control.c
> > > @@ -190,11 +190,13 @@ u32 omap4_ctrl_pad_readl(u16 offset)
> > > {
> > > return readl_relaxed(OMAP4_CTRL_PAD_REGADDR(offset));
> > > }
> > > +EXPORT_SYMBOL_GPL(omap4_ctrl_pad_readl);
> > >
> > > void omap4_ctrl_pad_writel(u32 val, u16 offset)
> > > {
> > > writel_relaxed(val, OMAP4_CTRL_PAD_REGADDR(offset));
> > > }
> > > +EXPORT_SYMBOL_GPL(omap4_ctrl_pad_writel);
> > >
> > > #ifdef CONFIG_ARCH_OMAP3
> > >
> > > diff --git a/drivers/staging/media/omap4iss/Kconfig
> > > b/drivers/staging/media/omap4iss/Kconfig index 78b0fba..0c3e3c1 100644
> > > --- a/drivers/staging/media/omap4iss/Kconfig
> > > +++ b/drivers/staging/media/omap4iss/Kconfig
> > > @@ -1,5 +1,5 @@
> > > config VIDEO_OMAP4
> > > - bool "OMAP 4 Camera support"
> > > + tristate "OMAP 4 Camera support"
> > > depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4
> > > select VIDEOBUF2_DMA_CONTIG
> > > ---help---
> >
> > This was discussed in detail here:
> > http://marc.info/?t=14019869251&r=1&w=2
> > Direct dependency from a staging driver to mach-omap2 driver is not
> > something we'd like, right?
>
> So it was decided to just leave ARM allmodconfig broken?
>
> Why not at least do this instead?
>
> 8<
> From 3a965f4fd5a6b3ef4a66aa4e7c916cfd34fd5706 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann
> Date: Tue, 21 Jan 2014 09:32:43 +0100
> Subject: [PATCH] [media] staging: tighten omap4iss dependencies
>
> The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
> of which can be loadable modules. This causes build failures
> if we want the camera driver to be built-in.
>
> This can be solved by turning the option into "tristate",
> which unfortunately causes another problem, because the
> driver incorrectly calls a platform-internal interface
> for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
>
> Instead, this patch just forbids the invalid configurations
> and ensures that the driver can only be built if all its
> dependencies are built-in.
>
> Signed-off-by: Arnd Bergmann
Acked-by: Laurent Pinchart
Should I take this in my tree for v3.17 or would you like to fast-track it ?
> diff --git a/drivers/staging/media/omap4iss/Kconfig
> b/drivers/staging/media/omap4iss/Kconfig index 78b0fba..8afc6fe 100644
> --- a/drivers/staging/media/omap4iss/Kconfig
> +++ b/drivers/staging/media/omap4iss/Kconfig
> @@ -1,6 +1,6 @@
> config VIDEO_OMAP4
> bool "OMAP 4 Camera support"
> - depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4
> + depends on VIDEO_V4L2=y && VIDEO_V4L2_SUBDEV_API && I2C=y && ARCH_OMAP4
> select VIDEOBUF2_DMA_CONTIG
> ---help---
> Driver for an OMAP 4 ISS controller.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On Thu, Jun 12, 2014 at 06:49:17PM +0530, Sricharan R wrote:
> Hi Jason,
>
> On Thursday 12 June 2014 06:21 PM, Jason Cooper wrote:
> > On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote:
> >> From: Nishanth Menon
> >>
> >> When, in the system due to varied reasons, interrupts might be unusable
> >> due to hardware behavior, but register maps do exist, then those interrupts
> >> should be skipped while mapping irq to crossbars.
> >>
> >> Signed-off-by: Nishanth Menon
> >> Signed-off-by: Sricharan R
> >> Signed-off-by: Tony Lindgren
> >
> > Tony, have you applied these somewhere already?
> >
> >> ---
> >> drivers/irqchip/irq-crossbar.c | 47
> >>
> >> 1 file changed, 43 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/irqchip/irq-crossbar.c
> >> b/drivers/irqchip/irq-crossbar.c
> >> index 51d4b87..847f6e3 100644
> >> --- a/drivers/irqchip/irq-crossbar.c
> >> +++ b/drivers/irqchip/irq-crossbar.c
> >> @@ -13,11 +13,13 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >>
> >> #define IRQ_FREE -1
> >> #define IRQ_RESERVED -2
> >> +#define IRQ_SKIP -3
> >> #define GIC_IRQ_START 32
> >>
> >> /*
> >> @@ -34,6 +36,16 @@ struct crossbar_device {
> >>void (*write) (int, int);
> >> };
> >>
> >> +/**
> >> + * struct crossbar_data: Platform specific data
> >> + * @irqs_unused: array of irqs that cannot be used because of hw erratas
> >> + * @size: size of the irqs_unused array
> >> + */
> >> +struct crossbar_data {
> >> + const uint *irqs_unused;
> >> + const uint size;
> >> +};
> >> +
> >> static struct crossbar_device *cb;
> >>
> >> static inline void crossbar_writel(int irq_no, int cb_no)
> >> @@ -119,10 +131,12 @@ const struct irq_domain_ops routable_irq_domain_ops
> >> = {
> >>.xlate = crossbar_domain_xlate
> >> };
> >>
> >> -static int __init crossbar_of_init(struct device_node *node)
> >> +static int __init crossbar_of_init(struct device_node *node,
> >> + const struct crossbar_data *data)
> >> {
> >>int i, size, max, reserved = 0, entry;
> >>const __be32 *irqsr;
> >> + const int *irqsk = NULL;
> >>
> >>cb = kzalloc(sizeof(*cb), GFP_KERNEL);
> >>
> >> @@ -194,6 +208,22 @@ static int __init crossbar_of_init(struct device_node
> >> *node)
> >>reserved += size;
> >>}
> >>
> >> + /* Skip the ones marked as unused */
> >> + if (data) {
> >> + irqsk = data->irqs_unused;
> >> + size = data->size;
> >> +
> >> + for (i = 0; i < size; i++) {
> >> + entry = irqsk[i];
> >> +
> >> + if (entry > max) {
> >> + pr_err("Invalid skip entry\n");
> >> + goto err3;
> >> + }
> >> + cb->irq_map[entry] = IRQ_SKIP;
> >> + }
> >> + }
> >> +
> >>register_routable_domain_ops(&routable_irq_domain_ops);
> >>return 0;
> >>
> >> @@ -208,18 +238,27 @@ err1:
> >>return -ENOMEM;
> >> }
> >>
> >> +/* irq number 10 cannot be used because of hw bug */
> >> +int dra_irqs_unused[] = { 10 };
> >> +struct crossbar_data cb_dra_data = { dra_irqs_unused,
> >> + ARRAY_SIZE(dra_irqs_unused) };
> >> +
> >> static const struct of_device_id crossbar_match[] __initconst = {
> >> - { .compatible = "ti,irq-crossbar" },
> >> + { .compatible = "ti,irq-crossbar", .data = &cb_dra_data },
> >>{}
> >> };
> >
> > This is a bug in all implementations of this IP? Or, a specific
> > SoC's implementation? Would this be better expressed in the dts via a
> > property? Can we expect future implementations to be fixed?
> >
> > thx,
> >
> > Jason.
> Infact this and PATCH#10 should be merged. I will change that.
>
> So in Socs's (2 so far) that do have a crossbar, some irqs are mapped
> through a crossbar and some are directly wired to the irqchip.
> These 'unused irqs' are those which are directly wired but they still
> have a crossbar register. Their routing cannot be changed. So this
> is not really expected usage of the crossbar hw ip. We initially thought
> having a dts property separately for this, but took this path to avoid
> loading the dts with additional bindings which may not be generic.
How do you plan to handle future SoCs with this IP and possibly
different hard-wired irqs?
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On Thu, Jun 12, 2014 at 06:57:15AM -0700, Tony Lindgren wrote: > * Jason Cooper [140612 05:52]: > > On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote: > > > From: Nishanth Menon > > > > > > When, in the system due to varied reasons, interrupts might be unusable > > > due to hardware behavior, but register maps do exist, then those > > > interrupts > > > should be skipped while mapping irq to crossbars. > > > > > > Signed-off-by: Nishanth Menon > > > Signed-off-by: Sricharan R > > > Signed-off-by: Tony Lindgren > > > > Tony, have you applied these somewhere already? > > I think some of these I had applied into a branch ready for > merging but then it was discovered that further changes > were needed and the branch was dropped. Ok. > Sricharan, please remove my Signed-off-by from this series. > If I end up applying it for merging my scripts will add it > automatically. Do you have other changes outside of irqchip depending on this series? If so, I can set up a topic branch for you guys to base off of. Otherwise, I'll just apply them to irqchip/core when they're ready. Also, Sricharan, when you respin this, please clearly identify (in the comment section) those patches that need to be flagged for stable. It would be helpful if they were the first patches in the series as well. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
* Jason Cooper [140612 05:52]: > On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote: > > From: Nishanth Menon > > > > When, in the system due to varied reasons, interrupts might be unusable > > due to hardware behavior, but register maps do exist, then those interrupts > > should be skipped while mapping irq to crossbars. > > > > Signed-off-by: Nishanth Menon > > Signed-off-by: Sricharan R > > Signed-off-by: Tony Lindgren > > Tony, have you applied these somewhere already? I think some of these I had applied into a branch ready for merging but then it was discovered that further changes were needed and the branch was dropped. Sricharan, please remove my Signed-off-by from this series. If I end up applying it for merging my scripts will add it automatically. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 16/19] irqchip: crossbar: introduce ti,max-crossbar-sources to identify valid crossbar mapping
On Thu, Jun 12, 2014 at 05:23:24PM +0530, Sricharan R wrote:
> From: Nishanth Menon
>
> Currently we attempt to map any crossbar value to an IRQ, however,
> this is not correct from hardware perspective. There is a max crossbar
> event number upto which hardware supports. So describe the same in
> device tree using 'ti,max-crossbar-sources' property and use it to
> validate requests.
>
> Signed-off-by: Nishanth Menon
> ---
> .../devicetree/bindings/arm/omap/crossbar.txt |2 ++
> drivers/irqchip/irq-crossbar.c | 21
> ++--
> 2 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> index fb88585..6d2e2f5 100644
> --- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> @@ -10,6 +10,7 @@ Required properties:
> - compatible : Should be "ti,irq-crossbar"
> - reg: Base address and the size of the crossbar registers.
> - ti,max-irqs: Total number of irqs available at the interrupt controller.
> +- ti,max-crossbar-sources: Maximum number of crossbar sources that can be
> routed.
> - ti,reg-size: Size of a individual register in bytes. Every individual
> register is assumed to be of same size. Valid sizes are 1, 2, 4.
> - ti,irqs-reserved: List of the reserved irq lines that are not muxed using
> @@ -22,6 +23,7 @@ Examples:
> compatible = "ti,irq-crossbar";
> reg = <0x4a002a48 0x130>;
> ti,max-irqs = <160>;
> + ti,max-crossbar-sources = <400>;
> ti,reg-size = <2>;
> ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
> };
> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
> index 2a73a66..cf69c4d 100644
> --- a/drivers/irqchip/irq-crossbar.c
> +++ b/drivers/irqchip/irq-crossbar.c
> @@ -26,6 +26,7 @@
> /**
> * struct crossbar_device - crossbar device descriptio
> * @int_max: maximum number of supported interrupts
> + * @max_crossbar_sources: Maximum number of crossbar sources
> * @irq_map: array of interrupts to crossbar number mapping
> * @crossbar_base: crossbar base address
> * @register_offsets: offsets for each irq number
> @@ -33,6 +34,7 @@
> */
> struct crossbar_device {
> uint int_max;
> + uint max_crossbar_sources;
> uint *irq_map;
> void __iomem *crossbar_base;
> int *register_offsets;
> @@ -126,12 +128,19 @@ static int crossbar_domain_xlate(struct irq_domain *d,
>unsigned int *out_type)
> {
> int ret;
> + int req_num = intspec[1];
>
> - ret = get_prev_map_irq(intspec[1]);
> + if (req_num >= cb->max_crossbar_sources) {
> + pr_err("%s: requested crossbar number %d > max %d\n",
> +__func__, req_num, cb->max_crossbar_sources);
> + return -EINVAL;
> + }
> +
> + ret = get_prev_map_irq(req_num);
> if (ret >= 0)
> goto found;
>
> - ret = allocate_free_irq(intspec[1]);
> + ret = allocate_free_irq(req_num);
>
> if (ret < 0)
> return ret;
> @@ -164,6 +173,14 @@ static int __init crossbar_of_init(struct device_node
> *node,
> if (!cb->crossbar_base)
> goto err_cb;
>
> + of_property_read_u32(node, "ti,max-crossbar-sources",
> + &cb->max_crossbar_sources);
> + if (!cb->max_crossbar_sources) {
> + pr_err("missing 'ti,max-crossbar-sources' property\n");
> + ret = -EINVAL;
> + goto err_base;
> + }
This completely breaks all boards using old dtbs. Please set
max_crossbar_sources to a sane value (400) when the property is missing.
> +
> of_property_read_u32(node, "ti,max-irqs", &max);
> if (!max) {
> pr_err("missing 'ti,max-irqs' property\n");
I know this is context, but you may want to look at this property as
well and set it to a sane value instead of erroring out.
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 15/19] irqchip: crossbar: Add kerneldoc for crossbar_domain_unmap callback
Hi Jason, On Thursday 12 June 2014 07:19 PM, Jason Cooper wrote: > On Thu, Jun 12, 2014 at 05:23:23PM +0530, Sricharan R wrote: >> The crossbar_domain_map/unmap callbacks need not be called same number >> of times for a particular irq. But still use counting is not needed >> here, because unmap(irq) gets called when irq_desc(irq) is disposed. >> After this the irq is anyways unusable and have to mapped again. > > There's no need to duplicate the code comment in the commit log ;-) Ok, will change this. > >> >> Adding the above kerneldoc for unmap callback clarity. >> >> Signed-off-by: Sricharan R >> --- >> drivers/irqchip/irq-crossbar.c | 10 ++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c >> index 5f3e75a..2a73a66 100644 >> --- a/drivers/irqchip/irq-crossbar.c >> +++ b/drivers/irqchip/irq-crossbar.c >> @@ -101,6 +101,16 @@ static int crossbar_domain_map(struct irq_domain *d, >> unsigned int irq, >> return 0; >> } >> >> +/** >> + * crossbar_domain_unmap - unmap a crossbar<->irq connection >> + * @d: domain of irq to unmap >> + * @irq: virq number >> + * >> + * The map/unmap callbacks need not be called same number of times for > > s/same/the same/ ok. > >> + * a particular irq. But still use counting is not needed here, because >> + * unmap(irq) gets called when irq_desc(irq) is disposed. After this the >> + * irq is anyways unusuable and have to be mapped again. > > Please re-word this. If I were new to the driver (I am ;-) ) I would > have no idea what this means (and I don't :( ) > hmm, will reword it better then.. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 15/19] irqchip: crossbar: Add kerneldoc for crossbar_domain_unmap callback
On Thu, Jun 12, 2014 at 05:23:23PM +0530, Sricharan R wrote:
> The crossbar_domain_map/unmap callbacks need not be called same number
> of times for a particular irq. But still use counting is not needed
> here, because unmap(irq) gets called when irq_desc(irq) is disposed.
> After this the irq is anyways unusable and have to mapped again.
There's no need to duplicate the code comment in the commit log ;-)
>
> Adding the above kerneldoc for unmap callback clarity.
>
> Signed-off-by: Sricharan R
> ---
> drivers/irqchip/irq-crossbar.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
> index 5f3e75a..2a73a66 100644
> --- a/drivers/irqchip/irq-crossbar.c
> +++ b/drivers/irqchip/irq-crossbar.c
> @@ -101,6 +101,16 @@ static int crossbar_domain_map(struct irq_domain *d,
> unsigned int irq,
> return 0;
> }
>
> +/**
> + * crossbar_domain_unmap - unmap a crossbar<->irq connection
> + * @d: domain of irq to unmap
> + * @irq: virq number
> + *
> + * The map/unmap callbacks need not be called same number of times for
s/same/the same/
> + * a particular irq. But still use counting is not needed here, because
> + * unmap(irq) gets called when irq_desc(irq) is disposed. After this the
> + * irq is anyways unusuable and have to be mapped again.
Please re-word this. If I were new to the driver (I am ;-) ) I would
have no idea what this means (and I don't :( )
thx,
Jason.
> + */
> static void crossbar_domain_unmap(struct irq_domain *d, unsigned int irq)
> {
> irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 13/19] irqchip: crossbar: change the goto naming
On Thu, Jun 12, 2014 at 05:23:21PM +0530, Sricharan R wrote:
> From: Nishanth Menon
>
> Using err1,2,3,4 etc makes it hard to ensure a new exit path in the
> middle will not result in spurious changes, so rename the error paths
> as per the function it does.
>
> Signed-off-by: Nishanth Menon
> ---
> drivers/irqchip/irq-crossbar.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
> index 524e6e9..cf0d79f 100644
> --- a/drivers/irqchip/irq-crossbar.c
> +++ b/drivers/irqchip/irq-crossbar.c
> @@ -152,17 +152,17 @@ static int __init crossbar_of_init(struct device_node
> *node,
>
> cb->crossbar_base = of_iomap(node, 0);
> if (!cb->crossbar_base)
> - goto err1;
> + goto err_cb;
>
> of_property_read_u32(node, "ti,max-irqs", &max);
> if (!max) {
> pr_err("missing 'ti,max-irqs' property\n");
> ret = -EINVAL;
> - goto err2;
> + goto err_base;
> }
> cb->irq_map = kcalloc(max, sizeof(int), GFP_KERNEL);
> if (!cb->irq_map)
> - goto err2;
> + goto err_base;
>
> cb->int_max = max;
>
> @@ -181,7 +181,7 @@ static int __init crossbar_of_init(struct device_node
> *node,
> if (entry > max) {
> pr_err("Invalid reserved entry\n");
> ret = -EINVAL;
> - goto err3;
> + goto err_irq_map;
> }
> cb->irq_map[entry] = IRQ_RESERVED;
> }
> @@ -189,7 +189,7 @@ static int __init crossbar_of_init(struct device_node
> *node,
>
> cb->register_offsets = kcalloc(max, sizeof(int), GFP_KERNEL);
> if (!cb->register_offsets)
> - goto err3;
> + goto err_irq_map;
>
> of_property_read_u32(node, "ti,reg-size", &size);
>
> @@ -206,7 +206,7 @@ static int __init crossbar_of_init(struct device_node
> *node,
> default:
> pr_err("Invalid reg-size property\n");
> ret = -EINVAL;
> - goto err4;
> + goto err_reg_offset;
> break;
> }
>
> @@ -234,7 +234,7 @@ static int __init crossbar_of_init(struct device_node
> *node,
> if (entry > max) {
> pr_err("Invalid skip entry\n");
> ret = -EINVAL;
> - goto err4;
> + goto err_reg_offset;
> }
> cb->irq_map[entry] = IRQ_SKIP;
> }
> @@ -251,13 +251,13 @@ static int __init crossbar_of_init(struct device_node
> *node,
> register_routable_domain_ops(&routable_irq_domain_ops);
> return 0;
>
> -err4:
> +err_reg_offset:
> kfree(cb->register_offsets);
> -err3:
> +err_irq_map:
> kfree(cb->irq_map);
> -err2:
> +err_base:
> iounmap(cb->crossbar_base);
> -err1:
> +err_cb:
> kfree(cb);
> return ret;
Ahhh :-) Ignore my previous request.
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 09/19] irqchip: crossbar: fix kerneldoc warning
Hi Jason, On Thursday 12 June 2014 06:44 PM, Jason Cooper wrote: > On Thu, Jun 12, 2014 at 05:23:17PM +0530, Sricharan R wrote: >> From: Nishanth Menon >> >> kernel doc style is wrong in code. fix it to squelch >> kerneldoc warnings: > > I would re-word the above to mention that we need to add missing > properties for kerneldoc (@write, @safemap), and we're doing some > cleanup of harmless warnings while we are here. > Ok, will do this. >> Warning(drivers/irqchip/irq-crossbar.c:27): missing initial short >> description on line: >> * struct crossbar_device: crossbar device description >> Info(drivers/irqchip/irq-crossbar.c:27): Scanning doc for struct >> Warning(drivers/irqchip/irq-crossbar.c:39): No description found for >> parameter 'write' >> Warning(drivers/irqchip/irq-crossbar.c:42): missing initial short >> description on line: >> * struct crossbar_data: Platform specific data >> Info(drivers/irqchip/irq-crossbar.c:42): Scanning doc for struct >> Warning(drivers/irqchip/irq-crossbar.c:50): No description found for >> parameter 'safe_map' >> 4 warnings >> >> Signed-off-by: Nishanth Menon >> --- >> drivers/irqchip/irq-crossbar.c |7 +-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c >> index 58790d4..7d4db07 100644 >> --- a/drivers/irqchip/irq-crossbar.c >> +++ b/drivers/irqchip/irq-crossbar.c >> @@ -23,11 +23,13 @@ >> #define IRQ_SKIP-3 >> #define GIC_IRQ_START 32 >> >> -/* >> +/** >> + * struct crossbar_device - crossbar device descriptio > > s/descriptio/description/ Ok, will correct. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 11/19] irqchip: crossbar: fix memory leak incase of invalid entry
Hi Jason,
On Thursday 12 June 2014 06:50 PM, Jason Cooper wrote:
> On Thu, Jun 12, 2014 at 05:23:19PM +0530, Sricharan R wrote:
>> From: Nishanth Menon
>>
>> When the provided unused skip list entry is greater than max irqs
>> possible, we go to err3, but we fail to free register_offsets,
>> should have returned to err4 instead which ensures that allocated
>
> s/returned/jumped/
ok, will correct.
>
>> register_offsets are freed as well.
>>
>> Signed-off-by: Nishanth Menon
>> ---
>> drivers/irqchip/irq-crossbar.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
>> index 42a2e62..fea3e5d 100644
>> --- a/drivers/irqchip/irq-crossbar.c
>> +++ b/drivers/irqchip/irq-crossbar.c
>> @@ -225,7 +225,7 @@ static int __init crossbar_of_init(struct device_node
>> *node,
>>
>> if (entry > max) {
>> pr_err("Invalid skip entry\n");
>> -goto err3;
>> +goto err4;
>
> This would be a good opportunity to reduce the possibility of future
> errors. Please consider renaming err{1,2,3,4} to something more
> recognizable while you are here.
>
Ok, this is done as a part of patch#13.
Regards,
Sricharan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 12/19] irqchip: crossbar: return proper error value
On Thu, Jun 12, 2014 at 05:23:20PM +0530, Sricharan R wrote:
> From: Nishanth Menon
>
> crossbar_of_init always returns -ENOMEM in case of errors, return proper
> error results in case of failures.
Please describe what the other possible failures are and how the changes
are more correct.
>
> Signed-off-by: Nishanth Menon
> ---
> drivers/irqchip/irq-crossbar.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
> index fea3e5d..524e6e9 100644
> --- a/drivers/irqchip/irq-crossbar.c
> +++ b/drivers/irqchip/irq-crossbar.c
> @@ -140,20 +140,26 @@ static const struct irq_domain_ops
> routable_irq_domain_ops = {
> static int __init crossbar_of_init(struct device_node *node,
> const struct crossbar_data *data)
> {
> - int i, size, max, reserved = 0, entry, safe_map;
> + int i, size, max = 0, reserved = 0, entry, safe_map;
> const __be32 *irqsr;
> const int *irqsk = NULL;
> + int ret = -ENOMEM;
>
> cb = kzalloc(sizeof(*cb), GFP_KERNEL);
>
> if (!cb)
> - return -ENOMEM;
> + return ret;
>
> cb->crossbar_base = of_iomap(node, 0);
> if (!cb->crossbar_base)
> goto err1;
>
> of_property_read_u32(node, "ti,max-irqs", &max);
> + if (!max) {
> + pr_err("missing 'ti,max-irqs' property\n");
> + ret = -EINVAL;
> + goto err2;
> + }
> cb->irq_map = kcalloc(max, sizeof(int), GFP_KERNEL);
> if (!cb->irq_map)
> goto err2;
> @@ -174,6 +180,7 @@ static int __init crossbar_of_init(struct device_node
> *node,
> i, &entry);
> if (entry > max) {
> pr_err("Invalid reserved entry\n");
> + ret = -EINVAL;
> goto err3;
> }
> cb->irq_map[entry] = IRQ_RESERVED;
> @@ -198,6 +205,7 @@ static int __init crossbar_of_init(struct device_node
> *node,
> break;
> default:
> pr_err("Invalid reg-size property\n");
> + ret = -EINVAL;
> goto err4;
> break;
> }
> @@ -225,6 +233,7 @@ static int __init crossbar_of_init(struct device_node
> *node,
>
> if (entry > max) {
> pr_err("Invalid skip entry\n");
> + ret = -EINVAL;
> goto err4;
> }
> cb->irq_map[entry] = IRQ_SKIP;
> @@ -250,7 +259,7 @@ err2:
> iounmap(cb->crossbar_base);
> err1:
> kfree(cb);
> - return -ENOMEM;
> + return ret;
> }
So, where is the change to the successful initialization? Shouldn't it
now set ret = 0?
This whole function seems to be a hodge-podge of different error
handling styles, which led to the memory leak fixed earlier in this
series.
Please go over this function, choose sane labels, and consolidate _all_
returns to the end of the function.
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 08/19] irqchip: crossbar: fix checkpatch warning
Hi Jason,
On Thursday 12 June 2014 06:40 PM, Jason Cooper wrote:
> On Thu, Jun 12, 2014 at 05:23:16PM +0530, Sricharan R wrote:
>> From: Nishanth Menon
>>
>> remove un-necessary space in function pointer.
>>
>> Fixes checkpatch warning:
>> WARNING: Unnecessary space before function pointer arguments
>> #37: FILE: drivers/irqchip/irq-crossbar.c:37:
>> + void (*write) (int, int);
>>
>> WARNING: Missing a blank line after declarations
>> +int *register_offsets;
>> +void (*write)(int, int);
>>
>> WARNING: Prefer kcalloc over kzalloc with multiply
>> +cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);
>>
>> WARNING: Prefer kcalloc over kzalloc with multiply
>> +cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
>>
>> Signed-off-by: Nishanth Menon
>> ---
>> drivers/irqchip/irq-crossbar.c |7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
>> index 5da9d36..58790d4 100644
>> --- a/drivers/irqchip/irq-crossbar.c
>> +++ b/drivers/irqchip/irq-crossbar.c
>> @@ -34,7 +34,8 @@ struct crossbar_device {
>> uint *irq_map;
>> void __iomem *crossbar_base;
>> int *register_offsets;
>> -void (*write) (int, int);
>> +
>> +void (*write)(int, int);
>
> The empty line here looks bogus to me. Did you re-run checkpatch after
> fixing the unnecessary space to see if it still complained about having
> a 'blank line after declarations'?
>
Yes, it still complains even after fixing unnecessary space.
WARNING: Missing a blank line after declarations
#37: FILE: ./drivers/irqchip/irq-crossbar.c:37:
+ int *register_offsets;
+ void (*write)(int, int);
>> };
>>
>> /**
>> @@ -150,7 +151,7 @@ static int __init crossbar_of_init(struct device_node
>> *node,
>> goto err1;
>>
>> of_property_read_u32(node, "ti,max-irqs", &max);
>> -cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);
>> +cb->irq_map = kcalloc(max, sizeof(int), GFP_KERNEL);
>> if (!cb->irq_map)
>> goto err2;
>>
>> @@ -176,7 +177,7 @@ static int __init crossbar_of_init(struct device_node
>> *node,
>> }
>> }
>>
>> -cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
>> +cb->register_offsets = kcalloc(max, sizeof(int), GFP_KERNEL);
>> if (!cb->register_offsets)
>> goto err3;
>
> I'm generally opposed to these sorts of checkpatch patches, especially
> when they are just warnings. It's great for a new driver in the staging
> tree, but it makes backporting future bugfixes that much harder when
> drivers have been live in mainline.
>
> If, in the future, you're changing code in this area, go ahead and
> convert to kcalloc(), but I wouldn't do a separate patch for this kind
> of thing.
>
> Honestly, I would just drop this patch and not worry about it.
>
Ok, but i just hope that there may not be real needs to make changes
for this driver in future. So if that's the case then it might be
better to fix it once for now.
Regards,
Sricharan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Handle non-secure L2C initialization on Exynos4
Hi Tomasz,
Thanks for working on this!
I have just tried this, against Linus master
64b2d1fbbfda07765dae3f601862796a61b2c451.
Added patch "ARM: dts: Initial ODROID U2 support" and booted on
ODROID-U2. I believe this board has the security enabled.
Unfortunately, it hangs during early boot. With earlyprintk the last
messages seen are:
L2C: platform modifies aux control register: 0x0207 -> 0x3e470001
L2C: platform provided aux values permit register corruption.
L2C: DT/platform modifies aux control register: 0x0207 -> 0x3e470001
L2C-310 enabling early BRESP for Cortex-A9
L2C-310: enabling full line of zeros but not enabled in Cortex-A9
L2C-310 ID prefetch enabled, offset 1 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 16 ways, 1024 kB
L2C-310: CACHE_ID 0x4100c4c8, AUX_CTRL 0x7e470001
I then tried to go back to the earlier patch "ARM: EXYNOS: Add secure
firmware support for l2x0 init" (attached, needed a rebase) but that
one also now hangs at:
L2C: platform modifies aux control register: 0x0207 -> 0x3e470001
It did work on 3.14 though. Looking at the changelogs, many changes
have been made to l2x0 recently. Can you confirm that you have tested
your patches against a kernel with all of Russell King's recent
changes?
Thanks
Daniel
From 2e67231f10ed0b05c2bacfdd05774fe21315d6da Mon Sep 17 00:00:00 2001
From: Gu1
Date: Mon, 21 Jan 2013 04:13:56 +0100
Subject: [PATCH] ARM: EXYNOS: Add secure firmware support for l2x0 init
Conflicts:
arch/arm/mm/cache-l2x0.c
---
arch/arm/mach-exynos/firmware.c | 19 +++
arch/arm/mm/cache-l2x0.c| 3 +++
2 files changed, 22 insertions(+)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index eb91d23..c200f77 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -16,6 +16,7 @@
#include
+#include
#include
#include "common.h"
@@ -64,10 +65,28 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long
boot_addr)
return 0;
}
+extern struct l2x0_regs l2x0_saved_regs;
+#define L2_AUX_VAL 0x7C470001
+#define L2_AUX_MASK 0xC200
+
+static int exynos_l2x0_init(void)
+{
+ exynos_smc(SMC_CMD_L2X0SETUP1, l2x0_saved_regs.tag_latency,
+ l2x0_saved_regs.data_latency,
+ l2x0_saved_regs.prefetch_ctrl);
+ exynos_smc(SMC_CMD_L2X0SETUP2, l2x0_saved_regs.pwr_ctrl,
+ L2_AUX_VAL, L2_AUX_MASK);
+ exynos_smc(SMC_CMD_L2X0INVALL, 0, 0, 0);
+ exynos_smc(SMC_CMD_L2X0CTRL, 1, 0, 0);
+ return 0;
+}
+
+
static const struct firmware_ops exynos_firmware_ops = {
.do_idle= exynos_do_idle,
.set_cpu_boot_addr = exynos_set_cpu_boot_addr,
.cpu_boot = exynos_cpu_boot,
+ .l2x0_init = exynos_l2x0_init,
};
void __init exynos_firmware_init(void)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index efc5cab..7367bef 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "cache-tauros3.h"
#include "cache-aurora-l2.h"
@@ -1504,6 +1505,8 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
if (data->of_parse)
data->of_parse(np, &aux_val, &aux_mask);
+ call_firmware_op(l2x0_init);
+
if (cache_id_part_number_from_dt)
cache_id = cache_id_part_number_from_dt;
else
--
1.9.1
Re: [PATCH V2 10/19] irqchip: crossbar: DRA7: Fix unused crossbar list
Hi Jason,
On Thursday 12 June 2014 06:46 PM, Jason Cooper wrote:
> On Thu, Jun 12, 2014 at 05:23:18PM +0530, Sricharan R wrote:
>> From: Rajendra Nayak
>>
>> On DRA7 compatible IRQ crossbar, IRQ 10 default mapped to L3_APP_IRQ,
>> IRQ133 is default mapped to NMI pin, 139 and 140 crossbars are
>> unused(not routed). Mark these as unused crossbar IRQs.
>>
>> Technical Reference Manual documentation update expected
>> DRA72x-TRMINC00067 is being used to track the update.
>>
>> Reported-by: Nishanth Menon
>> Reported-by: Sricharan R
>> Reported-by: Suman Anna
>> Signed-off-by: Rajendra Nayak
>> ---
>> drivers/irqchip/irq-crossbar.c |4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
>> index 7d4db07..42a2e62 100644
>> --- a/drivers/irqchip/irq-crossbar.c
>> +++ b/drivers/irqchip/irq-crossbar.c
>> @@ -253,8 +253,8 @@ err1:
>> return -ENOMEM;
>> }
>>
>> -/* irq number 10 cannot be used because of hw bug */
>> -static int dra_irqs_unused[] = { 10 };
>> +/* irq number 10,133,139 and 140 cannot be used because of hw bug */
>> +static int dra_irqs_unused[] = { 10 , 133, 139, 140 };
>
> see my earlier comment regarding a potential dts property.
>
Ok, if dts would be the better approach then I can change this.
Regards,
Sricharan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
Hi Jason,
On Thursday 12 June 2014 06:21 PM, Jason Cooper wrote:
> On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote:
>> From: Nishanth Menon
>>
>> When, in the system due to varied reasons, interrupts might be unusable
>> due to hardware behavior, but register maps do exist, then those interrupts
>> should be skipped while mapping irq to crossbars.
>>
>> Signed-off-by: Nishanth Menon
>> Signed-off-by: Sricharan R
>> Signed-off-by: Tony Lindgren
>
> Tony, have you applied these somewhere already?
>
>> ---
>> drivers/irqchip/irq-crossbar.c | 47
>>
>> 1 file changed, 43 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
>> index 51d4b87..847f6e3 100644
>> --- a/drivers/irqchip/irq-crossbar.c
>> +++ b/drivers/irqchip/irq-crossbar.c
>> @@ -13,11 +13,13 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> #define IRQ_FREE-1
>> #define IRQ_RESERVED-2
>> +#define IRQ_SKIP-3
>> #define GIC_IRQ_START 32
>>
>> /*
>> @@ -34,6 +36,16 @@ struct crossbar_device {
>> void (*write) (int, int);
>> };
>>
>> +/**
>> + * struct crossbar_data: Platform specific data
>> + * @irqs_unused: array of irqs that cannot be used because of hw erratas
>> + * @size: size of the irqs_unused array
>> + */
>> +struct crossbar_data {
>> +const uint *irqs_unused;
>> +const uint size;
>> +};
>> +
>> static struct crossbar_device *cb;
>>
>> static inline void crossbar_writel(int irq_no, int cb_no)
>> @@ -119,10 +131,12 @@ const struct irq_domain_ops routable_irq_domain_ops = {
>> .xlate = crossbar_domain_xlate
>> };
>>
>> -static int __init crossbar_of_init(struct device_node *node)
>> +static int __init crossbar_of_init(struct device_node *node,
>> + const struct crossbar_data *data)
>> {
>> int i, size, max, reserved = 0, entry;
>> const __be32 *irqsr;
>> +const int *irqsk = NULL;
>>
>> cb = kzalloc(sizeof(*cb), GFP_KERNEL);
>>
>> @@ -194,6 +208,22 @@ static int __init crossbar_of_init(struct device_node
>> *node)
>> reserved += size;
>> }
>>
>> +/* Skip the ones marked as unused */
>> +if (data) {
>> +irqsk = data->irqs_unused;
>> +size = data->size;
>> +
>> +for (i = 0; i < size; i++) {
>> +entry = irqsk[i];
>> +
>> +if (entry > max) {
>> +pr_err("Invalid skip entry\n");
>> +goto err3;
>> +}
>> +cb->irq_map[entry] = IRQ_SKIP;
>> +}
>> +}
>> +
>> register_routable_domain_ops(&routable_irq_domain_ops);
>> return 0;
>>
>> @@ -208,18 +238,27 @@ err1:
>> return -ENOMEM;
>> }
>>
>> +/* irq number 10 cannot be used because of hw bug */
>> +int dra_irqs_unused[] = { 10 };
>> +struct crossbar_data cb_dra_data = { dra_irqs_unused,
>> + ARRAY_SIZE(dra_irqs_unused) };
>> +
>> static const struct of_device_id crossbar_match[] __initconst = {
>> -{ .compatible = "ti,irq-crossbar" },
>> +{ .compatible = "ti,irq-crossbar", .data = &cb_dra_data },
>> {}
>> };
>
> This is a bug in all implementations of this IP? Or, a specific
> SoC's implementation? Would this be better expressed in the dts via a
> property? Can we expect future implementations to be fixed?
>
> thx,
>
> Jason.
Infact this and PATCH#10 should be merged. I will change that.
So in Socs's (2 so far) that do have a crossbar, some irqs are mapped
through a crossbar and some are directly wired to the irqchip.
These 'unused irqs' are those which are directly wired but they still
have a crossbar register. Their routing cannot be changed. So this
is not really expected usage of the crossbar hw ip. We initially thought
having a dts property separately for this, but took this path to avoid
loading the dts with additional bindings which may not be generic.
Regards,
Sricharan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 11/19] irqchip: crossbar: fix memory leak incase of invalid entry
On Thu, Jun 12, 2014 at 05:23:19PM +0530, Sricharan R wrote:
> From: Nishanth Menon
>
> When the provided unused skip list entry is greater than max irqs
> possible, we go to err3, but we fail to free register_offsets,
> should have returned to err4 instead which ensures that allocated
s/returned/jumped/
> register_offsets are freed as well.
>
> Signed-off-by: Nishanth Menon
> ---
> drivers/irqchip/irq-crossbar.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
> index 42a2e62..fea3e5d 100644
> --- a/drivers/irqchip/irq-crossbar.c
> +++ b/drivers/irqchip/irq-crossbar.c
> @@ -225,7 +225,7 @@ static int __init crossbar_of_init(struct device_node
> *node,
>
> if (entry > max) {
> pr_err("Invalid skip entry\n");
> - goto err3;
> + goto err4;
This would be a good opportunity to reduce the possibility of future
errors. Please consider renaming err{1,2,3,4} to something more
recognizable while you are here.
thx,
Jason.
> }
> cb->irq_map[entry] = IRQ_SKIP;
> }
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 10/19] irqchip: crossbar: DRA7: Fix unused crossbar list
On Thu, Jun 12, 2014 at 05:23:18PM +0530, Sricharan R wrote:
> From: Rajendra Nayak
>
> On DRA7 compatible IRQ crossbar, IRQ 10 default mapped to L3_APP_IRQ,
> IRQ133 is default mapped to NMI pin, 139 and 140 crossbars are
> unused(not routed). Mark these as unused crossbar IRQs.
>
> Technical Reference Manual documentation update expected
> DRA72x-TRMINC00067 is being used to track the update.
>
> Reported-by: Nishanth Menon
> Reported-by: Sricharan R
> Reported-by: Suman Anna
> Signed-off-by: Rajendra Nayak
> ---
> drivers/irqchip/irq-crossbar.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
> index 7d4db07..42a2e62 100644
> --- a/drivers/irqchip/irq-crossbar.c
> +++ b/drivers/irqchip/irq-crossbar.c
> @@ -253,8 +253,8 @@ err1:
> return -ENOMEM;
> }
>
> -/* irq number 10 cannot be used because of hw bug */
> -static int dra_irqs_unused[] = { 10 };
> +/* irq number 10,133,139 and 140 cannot be used because of hw bug */
> +static int dra_irqs_unused[] = { 10 , 133, 139, 140 };
see my earlier comment regarding a potential dts property.
thx,
Jason.
> static struct crossbar_data cb_dra_data = { dra_irqs_unused,
>ARRAY_SIZE(dra_irqs_unused), 0 };
>
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 09/19] irqchip: crossbar: fix kerneldoc warning
On Thu, Jun 12, 2014 at 05:23:17PM +0530, Sricharan R wrote:
> From: Nishanth Menon
>
> kernel doc style is wrong in code. fix it to squelch
> kerneldoc warnings:
I would re-word the above to mention that we need to add missing
properties for kerneldoc (@write, @safemap), and we're doing some
cleanup of harmless warnings while we are here.
> Warning(drivers/irqchip/irq-crossbar.c:27): missing initial short description
> on line:
> * struct crossbar_device: crossbar device description
> Info(drivers/irqchip/irq-crossbar.c:27): Scanning doc for struct
> Warning(drivers/irqchip/irq-crossbar.c:39): No description found for
> parameter 'write'
> Warning(drivers/irqchip/irq-crossbar.c:42): missing initial short description
> on line:
> * struct crossbar_data: Platform specific data
> Info(drivers/irqchip/irq-crossbar.c:42): Scanning doc for struct
> Warning(drivers/irqchip/irq-crossbar.c:50): No description found for
> parameter 'safe_map'
> 4 warnings
>
> Signed-off-by: Nishanth Menon
> ---
> drivers/irqchip/irq-crossbar.c |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
> index 58790d4..7d4db07 100644
> --- a/drivers/irqchip/irq-crossbar.c
> +++ b/drivers/irqchip/irq-crossbar.c
> @@ -23,11 +23,13 @@
> #define IRQ_SKIP -3
> #define GIC_IRQ_START32
>
> -/*
> +/**
> + * struct crossbar_device - crossbar device descriptio
s/descriptio/description/
thx,
Jason.
> * @int_max: maximum number of supported interrupts
> * @irq_map: array of interrupts to crossbar number mapping
> * @crossbar_base: crossbar base address
> * @register_offsets: offsets for each irq number
> + * @write: register write function pointer
> */
> struct crossbar_device {
> uint int_max;
> @@ -39,9 +41,10 @@ struct crossbar_device {
> };
>
> /**
> - * struct crossbar_data: Platform specific data
> + * struct crossbar_data - Platform specific data
> * @irqs_unused: array of irqs that cannot be used because of hw erratas
> * @size: size of the irqs_unused array
> + * @safe_map: safe value to write to crossbar register
> */
> struct crossbar_data {
> const uint *irqs_unused;
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 08/19] irqchip: crossbar: fix checkpatch warning
On Thu, Jun 12, 2014 at 05:23:16PM +0530, Sricharan R wrote:
> From: Nishanth Menon
>
> remove un-necessary space in function pointer.
>
> Fixes checkpatch warning:
> WARNING: Unnecessary space before function pointer arguments
> #37: FILE: drivers/irqchip/irq-crossbar.c:37:
> +void (*write) (int, int);
>
> WARNING: Missing a blank line after declarations
> + int *register_offsets;
> + void (*write)(int, int);
>
> WARNING: Prefer kcalloc over kzalloc with multiply
> + cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);
>
> WARNING: Prefer kcalloc over kzalloc with multiply
> + cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
>
> Signed-off-by: Nishanth Menon
> ---
> drivers/irqchip/irq-crossbar.c |7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
> index 5da9d36..58790d4 100644
> --- a/drivers/irqchip/irq-crossbar.c
> +++ b/drivers/irqchip/irq-crossbar.c
> @@ -34,7 +34,8 @@ struct crossbar_device {
> uint *irq_map;
> void __iomem *crossbar_base;
> int *register_offsets;
> - void (*write) (int, int);
> +
> + void (*write)(int, int);
The empty line here looks bogus to me. Did you re-run checkpatch after
fixing the unnecessary space to see if it still complained about having
a 'blank line after declarations'?
> };
>
> /**
> @@ -150,7 +151,7 @@ static int __init crossbar_of_init(struct device_node
> *node,
> goto err1;
>
> of_property_read_u32(node, "ti,max-irqs", &max);
> - cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);
> + cb->irq_map = kcalloc(max, sizeof(int), GFP_KERNEL);
> if (!cb->irq_map)
> goto err2;
>
> @@ -176,7 +177,7 @@ static int __init crossbar_of_init(struct device_node
> *node,
> }
> }
>
> - cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
> + cb->register_offsets = kcalloc(max, sizeof(int), GFP_KERNEL);
> if (!cb->register_offsets)
> goto err3;
I'm generally opposed to these sorts of checkpatch patches, especially
when they are just warnings. It's great for a new driver in the staging
tree, but it makes backporting future bugfixes that much harder when
drivers have been live in mainline.
If, in the future, you're changing code in this area, go ahead and
convert to kcalloc(), but I wouldn't do a separate patch for this kind
of thing.
Honestly, I would just drop this patch and not worry about it.
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 05/19] irqchip: crossbar: Change allocation logic by reversing search for free irqs
On Thu, Jun 12, 2014 at 05:23:13PM +0530, Sricharan R wrote:
> From: Nishanth Menon
>
> Reverse the search algorithm to ensure that address mapping and IRQ
> allocation logics are proper. This can open up new bugs which are
> easily fixable rather than wait till allocation logic approaches
> the limit to find new bugs.
Could you expand on this logic some more? What class of bugs are you
hoping to discover more easily?
thx,
Jason.
> Signed-off-by: Nishanth Menon
> Signed-off-by: Sricharan R
> Signed-off-by: Tony Lindgren
> ---
> drivers/irqchip/irq-crossbar.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
> index 287d3ce..de021638 100644
> --- a/drivers/irqchip/irq-crossbar.c
> +++ b/drivers/irqchip/irq-crossbar.c
> @@ -68,7 +68,7 @@ static inline int get_prev_map_irq(int cb_no)
> {
> int i;
>
> - for (i = 0; i < cb->int_max; i++)
> + for (i = cb->int_max - 1; i >= 0; i--)
> if (cb->irq_map[i] == cb_no)
> return i;
>
> @@ -79,7 +79,7 @@ static inline int allocate_free_irq(int cb_no)
> {
> int i;
>
> - for (i = 0; i < cb->int_max; i++) {
> + for (i = cb->int_max - 1; i >= 0; i--) {
> if (cb->irq_map[i] == IRQ_FREE) {
> cb->irq_map[i] = cb_no;
> return i;
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote:
> From: Nishanth Menon
>
> When, in the system due to varied reasons, interrupts might be unusable
> due to hardware behavior, but register maps do exist, then those interrupts
> should be skipped while mapping irq to crossbars.
>
> Signed-off-by: Nishanth Menon
> Signed-off-by: Sricharan R
> Signed-off-by: Tony Lindgren
Tony, have you applied these somewhere already?
> ---
> drivers/irqchip/irq-crossbar.c | 47
>
> 1 file changed, 43 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
> index 51d4b87..847f6e3 100644
> --- a/drivers/irqchip/irq-crossbar.c
> +++ b/drivers/irqchip/irq-crossbar.c
> @@ -13,11 +13,13 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> #define IRQ_FREE -1
> #define IRQ_RESERVED -2
> +#define IRQ_SKIP -3
> #define GIC_IRQ_START32
>
> /*
> @@ -34,6 +36,16 @@ struct crossbar_device {
> void (*write) (int, int);
> };
>
> +/**
> + * struct crossbar_data: Platform specific data
> + * @irqs_unused: array of irqs that cannot be used because of hw erratas
> + * @size: size of the irqs_unused array
> + */
> +struct crossbar_data {
> + const uint *irqs_unused;
> + const uint size;
> +};
> +
> static struct crossbar_device *cb;
>
> static inline void crossbar_writel(int irq_no, int cb_no)
> @@ -119,10 +131,12 @@ const struct irq_domain_ops routable_irq_domain_ops = {
> .xlate = crossbar_domain_xlate
> };
>
> -static int __init crossbar_of_init(struct device_node *node)
> +static int __init crossbar_of_init(struct device_node *node,
> +const struct crossbar_data *data)
> {
> int i, size, max, reserved = 0, entry;
> const __be32 *irqsr;
> + const int *irqsk = NULL;
>
> cb = kzalloc(sizeof(*cb), GFP_KERNEL);
>
> @@ -194,6 +208,22 @@ static int __init crossbar_of_init(struct device_node
> *node)
> reserved += size;
> }
>
> + /* Skip the ones marked as unused */
> + if (data) {
> + irqsk = data->irqs_unused;
> + size = data->size;
> +
> + for (i = 0; i < size; i++) {
> + entry = irqsk[i];
> +
> + if (entry > max) {
> + pr_err("Invalid skip entry\n");
> + goto err3;
> + }
> + cb->irq_map[entry] = IRQ_SKIP;
> + }
> + }
> +
> register_routable_domain_ops(&routable_irq_domain_ops);
> return 0;
>
> @@ -208,18 +238,27 @@ err1:
> return -ENOMEM;
> }
>
> +/* irq number 10 cannot be used because of hw bug */
> +int dra_irqs_unused[] = { 10 };
> +struct crossbar_data cb_dra_data = { dra_irqs_unused,
> + ARRAY_SIZE(dra_irqs_unused) };
> +
> static const struct of_device_id crossbar_match[] __initconst = {
> - { .compatible = "ti,irq-crossbar" },
> + { .compatible = "ti,irq-crossbar", .data = &cb_dra_data },
> {}
> };
This is a bug in all implementations of this IP? Or, a specific
SoC's implementation? Would this be better expressed in the dts via a
property? Can we expect future implementations to be fixed?
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/4] ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods
Tony,
We need this one as well for 3.16.
cheers,
-roger
On 04/23/2014 08:35 PM, Roger Quadros wrote:
> From: Nikhil Devshatwar
>
> Add hwmods for ocp2scp3 and sata modules.
>
> [Roger Q] Clean up.
>
> CC: Benoit Cousson
> CC: Paul Walmsley
> Signed-off-by: Balaji T K
> Signed-off-by: Nikhil Devshatwar
> Signed-off-by: Roger Quadros
> ---
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 31
> ++-
> 1 file changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 810c205..b02a4ab 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1215,6 +1215,30 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
> },
> };
>
> +/* ocp2scp3 */
> +static struct omap_hwmod dra7xx_ocp2scp3_hwmod;
> +
> +/* l4_cfg -> ocp2scp3 */
> +static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = {
> + .master = &dra7xx_l4_cfg_hwmod,
> + .slave = &dra7xx_ocp2scp3_hwmod,
> + .clk= "l4_root_clk_div",
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
> + .name = "ocp2scp3",
> + .class = &dra7xx_ocp2scp_hwmod_class,
> + .clkdm_name = "l3init_clkdm",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs =
> DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
> + .context_offs =
> DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
> + .modulemode = MODULEMODE_HWCTRL,
> + },
> + },
> +};
> +
> /*
> * 'qspi' class
> *
> @@ -1268,9 +1292,6 @@ static struct omap_hwmod_class dra7xx_sata_hwmod_class
> = {
> };
>
> /* sata */
> -static struct omap_hwmod_opt_clk sata_opt_clks[] = {
> - { .role = "ref_clk", .clk = "sata_ref_clk" },
> -};
>
> static struct omap_hwmod dra7xx_sata_hwmod = {
> .name = "sata",
> @@ -1278,6 +1299,7 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
> .clkdm_name = "l3init_clkdm",
> .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
> .main_clk = "func_48m_fclk",
> + .mpu_rt_idx = 1,
> .prcm = {
> .omap4 = {
> .clkctrl_offs = DRA7XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
> @@ -1285,8 +1307,6 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
> .modulemode = MODULEMODE_SWCTRL,
> },
> },
> - .opt_clks = sata_opt_clks,
> - .opt_clks_cnt = ARRAY_SIZE(sata_opt_clks),
> };
>
> /*
> @@ -2682,6 +2702,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
> __initdata = {
> &dra7xx_l4_per1__mmc4,
> &dra7xx_l4_cfg__mpu,
> &dra7xx_l4_cfg__ocp2scp1,
> + &dra7xx_l4_cfg__ocp2scp3,
> &dra7xx_l3_main_1__qspi,
> &dra7xx_l4_cfg__sata,
> &dra7xx_l4_cfg__smartreflex_core,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/4] ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods
Tony,
Looks like we've missed this for 3.16.
cheers,
-roger
On 04/23/2014 08:34 PM, Roger Quadros wrote:
> From: Keshava Munegowda
>
> Create hwmods for ocp2scp3 and sata modules.
>
> [Roger Q] Clean up.
>
> CC: Benoit Cousson
> Acked-by: Paul Walmsley
> Signed-off-by: Balaji T K
> Signed-off-by: Roger Quadros
> ---
> arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 73
> ++
> 1 file changed, 73 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> index 8923172..e169f90 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> @@ -1791,6 +1791,77 @@ static struct omap_hwmod omap54xx_wd_timer2_hwmod = {
> },
> };
>
> +/*
> + * 'ocp2scp' class
> + * bridge to transform ocp interface protocol to scp (serial control port)
> + * protocol
> + */
> +/* ocp2scp3 */
> +static struct omap_hwmod omap54xx_ocp2scp3_hwmod;
> +/* l4_cfg -> ocp2scp3 */
> +static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp3 = {
> + .master = &omap54xx_l4_cfg_hwmod,
> + .slave = &omap54xx_ocp2scp3_hwmod,
> + .clk= "l4_root_clk_div",
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +static struct omap_hwmod omap54xx_ocp2scp3_hwmod = {
> + .name = "ocp2scp3",
> + .class = &omap54xx_ocp2scp_hwmod_class,
> + .clkdm_name = "l3init_clkdm",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs =
> OMAP54XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
> + .context_offs =
> OMAP54XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
> + .modulemode = MODULEMODE_HWCTRL,
> + },
> + },
> +};
> +
> +/*
> + * 'sata' class
> + * sata: serial ata interface gen2 compliant ( 1 rx/ 1 tx)
> + */
> +
> +static struct omap_hwmod_class_sysconfig omap54xx_sata_sysc = {
> + .sysc_offs = 0x,
> + .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
> + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> +SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
> +MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
> + .sysc_fields= &omap_hwmod_sysc_type2,
> +};
> +
> +static struct omap_hwmod_class omap54xx_sata_hwmod_class = {
> + .name = "sata",
> + .sysc = &omap54xx_sata_sysc,
> +};
> +
> +/* sata */
> +static struct omap_hwmod omap54xx_sata_hwmod = {
> + .name = "sata",
> + .class = &omap54xx_sata_hwmod_class,
> + .clkdm_name = "l3init_clkdm",
> + .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
> + .main_clk = "func_48m_fclk",
> + .mpu_rt_idx = 1,
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs = OMAP54XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
> + .context_offs = OMAP54XX_RM_L3INIT_SATA_CONTEXT_OFFSET,
> + .modulemode = MODULEMODE_SWCTRL,
> + },
> + },
> +};
> +
> +/* l4_cfg -> sata */
> +static struct omap_hwmod_ocp_if omap54xx_l4_cfg__sata = {
> + .master = &omap54xx_l4_cfg_hwmod,
> + .slave = &omap54xx_sata_hwmod,
> + .clk= "l3_iclk_div",
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
>
> /*
> * Interfaces
> @@ -2482,6 +2553,8 @@ static struct omap_hwmod_ocp_if
> *omap54xx_hwmod_ocp_ifs[] __initdata = {
> &omap54xx_l4_cfg__usb_tll_hs,
> &omap54xx_l4_cfg__usb_otg_ss,
> &omap54xx_l4_wkup__wd_timer2,
> + &omap54xx_l4_cfg__ocp2scp3,
> + &omap54xx_l4_cfg__sata,
> NULL,
> };
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
From: Nishanth Menon
When, in the system due to varied reasons, interrupts might be unusable
due to hardware behavior, but register maps do exist, then those interrupts
should be skipped while mapping irq to crossbars.
Signed-off-by: Nishanth Menon
Signed-off-by: Sricharan R
Signed-off-by: Tony Lindgren
---
drivers/irqchip/irq-crossbar.c | 47
1 file changed, 43 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 51d4b87..847f6e3 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -13,11 +13,13 @@
#include
#include
#include
+#include
#include
#include
#define IRQ_FREE -1
#define IRQ_RESERVED -2
+#define IRQ_SKIP -3
#define GIC_IRQ_START 32
/*
@@ -34,6 +36,16 @@ struct crossbar_device {
void (*write) (int, int);
};
+/**
+ * struct crossbar_data: Platform specific data
+ * @irqs_unused: array of irqs that cannot be used because of hw erratas
+ * @size: size of the irqs_unused array
+ */
+struct crossbar_data {
+ const uint *irqs_unused;
+ const uint size;
+};
+
static struct crossbar_device *cb;
static inline void crossbar_writel(int irq_no, int cb_no)
@@ -119,10 +131,12 @@ const struct irq_domain_ops routable_irq_domain_ops = {
.xlate = crossbar_domain_xlate
};
-static int __init crossbar_of_init(struct device_node *node)
+static int __init crossbar_of_init(struct device_node *node,
+ const struct crossbar_data *data)
{
int i, size, max, reserved = 0, entry;
const __be32 *irqsr;
+ const int *irqsk = NULL;
cb = kzalloc(sizeof(*cb), GFP_KERNEL);
@@ -194,6 +208,22 @@ static int __init crossbar_of_init(struct device_node
*node)
reserved += size;
}
+ /* Skip the ones marked as unused */
+ if (data) {
+ irqsk = data->irqs_unused;
+ size = data->size;
+
+ for (i = 0; i < size; i++) {
+ entry = irqsk[i];
+
+ if (entry > max) {
+ pr_err("Invalid skip entry\n");
+ goto err3;
+ }
+ cb->irq_map[entry] = IRQ_SKIP;
+ }
+ }
+
register_routable_domain_ops(&routable_irq_domain_ops);
return 0;
@@ -208,18 +238,27 @@ err1:
return -ENOMEM;
}
+/* irq number 10 cannot be used because of hw bug */
+int dra_irqs_unused[] = { 10 };
+struct crossbar_data cb_dra_data = { dra_irqs_unused,
+ARRAY_SIZE(dra_irqs_unused) };
+
static const struct of_device_id crossbar_match[] __initconst = {
- { .compatible = "ti,irq-crossbar" },
+ { .compatible = "ti,irq-crossbar", .data = &cb_dra_data },
{}
};
int __init irqcrossbar_init(void)
{
struct device_node *np;
- np = of_find_matching_node(NULL, crossbar_match);
+ const struct of_device_id *of_id;
+ const struct crossbar_data *cdata;
+
+ np = of_find_matching_node_and_match(NULL, crossbar_match, &of_id);
if (!np)
return -ENODEV;
- crossbar_of_init(np);
+ cdata = of_id->data;
+ crossbar_of_init(np, cdata);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 00/19] irqchip: crossbar: driver fixes
This series does some cleanups, fixes for handling two interrupts getting mapped twice to same crossbar and provides support for hardwired IRQ and crossbar definitions. On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10, 131, 132, 133 are direct wired to hardware blocks bypassing crossbar. This quirky implementation is *NOT* supposed to be the expectation of crossbar hardware usage. This series adds support to represent such hard-wired irqs through DT and avoid generic allocation/programming of crossbar in the driver. This way of supporting hard-wired irqs was a result of the below discussions. http://www.spinics.net/lists/arm-kernel/msg329946.html Based on 3.15 mainline. All the patches are available here g...@github.com:Sricharanti/sricharan.git crossbar_updates The fixes series[1] earlier posted is merged in to this. [1] http://www.spinics.net/lists/arm-kernel/msg328273.html [V2] Merged the above series and rebased on 3.15 mainline Nishanth Menon (16): irqchip: crossbar: dont use '0' to mark reserved interrupts irqchip: crossbar: check for premapped crossbar before allocating irqchip: crossbar: Skip some irqs from getting mapped to crossbar irqchip: crossbar: Initialise the crossbar with a safe value irqchip: crossbar: Change allocation logic by reversing search for free irqs irqchip: crossbar: remove IS_ERR_VALUE check irqchip: crossbar: fix sparse warnings irqchip: crossbar: fix checkpatch warning irqchip: crossbar: fix kerneldoc warning irqchip: crossbar: fix memory leak incase of invalid entry irqchip: crossbar: return proper error value irqchip: crossbar: change the goto naming irqchip: crossbar: introduce ti,max-crossbar-sources to identify valid crossbar mapping irqchip: crossbar: introduce centralized check for crossbar write Documentation: dt: OMAP: crossbar: add description for interrupt consumer irqchip: crossbar allow for quirky hardware with direct hardwiring of GIC Rajendra Nayak (1): irqchip: crossbar: DRA7: Fix unused crossbar list Sricharan R (2): irqchip: crossbar: set cb pointer to null in case of error irqchip: crossbar: Add kerneldoc for crossbar_domain_unmap callback .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++ drivers/irqchip/irq-crossbar.c | 193 +--- 2 files changed, 191 insertions(+), 29 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 0/2] ARM: dts: dra7: Add crossbar dt support
This series introduces DT support for crossbar device and changes dra7 peripherals to use crossbar number instead of irq. This depends on below driver fixes and cleanup series. https://lkml.org/lkml/2014/6/12/232 [V2] Rebased on 3.15 mainline. R Sricharan (2): ARM: dts: DRA7: Add routable-irqs property for gic node ARM: dts: DRA7: Add crossbar device binding arch/arm/boot/dts/dra7.dtsi | 134 --- 1 file changed, 76 insertions(+), 58 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 06/19] irqchip: crossbar: remove IS_ERR_VALUE check
From: Nishanth Menon
IS_ERR_VALUE makes sense only *if* there could be valid values in
negative error range. But in the cases that we do use it, there is no
such case. Just remove the same.
Signed-off-by: Nishanth Menon
---
drivers/irqchip/irq-crossbar.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index de021638..c5415ae 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -110,15 +110,15 @@ static int crossbar_domain_xlate(struct irq_domain *d,
unsigned long *out_hwirq,
unsigned int *out_type)
{
- unsigned long ret;
+ int ret;
ret = get_prev_map_irq(intspec[1]);
- if (!IS_ERR_VALUE(ret))
+ if (ret >= 0)
goto found;
ret = allocate_free_irq(intspec[1]);
- if (IS_ERR_VALUE(ret))
+ if (ret < 0)
return ret;
found:
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 05/19] irqchip: crossbar: Change allocation logic by reversing search for free irqs
From: Nishanth Menon
Reverse the search algorithm to ensure that address mapping and IRQ
allocation logics are proper. This can open up new bugs which are
easily fixable rather than wait till allocation logic approaches
the limit to find new bugs.
Signed-off-by: Nishanth Menon
Signed-off-by: Sricharan R
Signed-off-by: Tony Lindgren
---
drivers/irqchip/irq-crossbar.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 287d3ce..de021638 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -68,7 +68,7 @@ static inline int get_prev_map_irq(int cb_no)
{
int i;
- for (i = 0; i < cb->int_max; i++)
+ for (i = cb->int_max - 1; i >= 0; i--)
if (cb->irq_map[i] == cb_no)
return i;
@@ -79,7 +79,7 @@ static inline int allocate_free_irq(int cb_no)
{
int i;
- for (i = 0; i < cb->int_max; i++) {
+ for (i = cb->int_max - 1; i >= 0; i--) {
if (cb->irq_map[i] == IRQ_FREE) {
cb->irq_map[i] = cb_no;
return i;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/2] ARM: dts: DRA7: Add routable-irqs property for gic node
From: R Sricharan There is a IRQ crossbar device in the soc, which maps the irq requests from the peripherals to the mpu interrupt controller's inputs. The gic provides the support for such IPs in the form of routable-irqs. So adding the property here to gic node. Signed-off-by: Sricharan R Signed-off-by: Nishanth Menon Cc: Benoit Cousson Cc: Santosh Shilimkar Cc: Rajendra Nayak Cc: Tony Lindgren Tested-by: Darren Etheridge Tested-by: Roger Quadros --- arch/arm/boot/dts/dra7.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index c29945e..1cf4ee1 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -45,6 +45,7 @@ compatible = "arm,cortex-a15-gic"; interrupt-controller; #interrupt-cells = <3>; + arm,routable-irqs = <192>; reg = <0x48211000 0x1000>, <0x48212000 0x1000>, <0x48214000 0x2000>, -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 2/2] ARM: dts: DRA7: Add crossbar device binding
From: R Sricharan
There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. The crossbar device is used to map
a peripheral input to a free mpu's interrupt controller line.
Here, adding a new crossbar device node and replacing all the peripheral
interrupt numbers with its fixed crossbar input lines.
Signed-off-by: Sricharan R
Signed-off-by: Nishanth Menon
Cc: Benoit Cousson
Cc: Santosh Shilimkar
Cc: Rajendra Nayak
Cc: Tony Lindgren
Tested-by: Darren Etheridge
Tested-by: Roger Quadros
---
arch/arm/boot/dts/dra7.dtsi | 133 ---
1 file changed, 75 insertions(+), 58 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1cf4ee1..0fedbcd 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -80,8 +80,8 @@
ti,hwmods = "l3_main_1", "l3_main_2";
reg = <0x4400 0x100>,
<0x4500 0x1000>;
- interrupts = ,
-;
+ interrupts = ,
+;
prm: prm@4ae06000 {
compatible = "ti,dra7-prm";
@@ -156,10 +156,10 @@
sdma: dma-controller@4a056000 {
compatible = "ti,omap4430-sdma";
reg = <0x4a056000 0x1000>;
- interrupts = ,
-,
-,
-;
+ interrupts = ,
+,
+,
+;
#dma-cells = <1>;
#dma-channels = <32>;
#dma-requests = <127>;
@@ -168,7 +168,7 @@
gpio1: gpio@4ae1 {
compatible = "ti,omap4-gpio";
reg = <0x4ae1 0x200>;
- interrupts = ;
+ interrupts = ;
ti,hwmods = "gpio1";
gpio-controller;
#gpio-cells = <2>;
@@ -179,7 +179,7 @@
gpio2: gpio@48055000 {
compatible = "ti,omap4-gpio";
reg = <0x48055000 0x200>;
- interrupts = ;
+ interrupts = ;
ti,hwmods = "gpio2";
gpio-controller;
#gpio-cells = <2>;
@@ -190,7 +190,7 @@
gpio3: gpio@48057000 {
compatible = "ti,omap4-gpio";
reg = <0x48057000 0x200>;
- interrupts = ;
+ interrupts = ;
ti,hwmods = "gpio3";
gpio-controller;
#gpio-cells = <2>;
@@ -201,7 +201,7 @@
gpio4: gpio@48059000 {
compatible = "ti,omap4-gpio";
reg = <0x48059000 0x200>;
- interrupts = ;
+ interrupts = ;
ti,hwmods = "gpio4";
gpio-controller;
#gpio-cells = <2>;
@@ -212,7 +212,7 @@
gpio5: gpio@4805b000 {
compatible = "ti,omap4-gpio";
reg = <0x4805b000 0x200>;
- interrupts = ;
+ interrupts = ;
ti,hwmods = "gpio5";
gpio-controller;
#gpio-cells = <2>;
@@ -223,7 +223,7 @@
gpio6: gpio@4805d000 {
compatible = "ti,omap4-gpio";
reg = <0x4805d000 0x200>;
- interrupts = ;
+ interrupts = ;
ti,hwmods = "gpio6";
gpio-controller;
#gpio-cells = <2>;
@@ -234,7 +234,7 @@
gpio7: gpio@48051000 {
compatible = "ti,omap4-gpio";
reg = <0x48051000 0x200>;
- interrupts = ;
+ interrupts = ;
ti,hwmods = "gpio7";
gpio-controller;
#gpio-cells = <2>;
@@ -245,7 +245,7 @@
gpio8: gpio@48053000 {
compatible = "ti,omap4-gpio";
reg = <0x48053000 0x200>;
- interrupts = ;
+ interrupts = ;
ti,hwmods = "gpio8";
gpio-controller;
#gpio-cells = <2>;
@@ -256
[PATCH V2 04/19] irqchip: crossbar: Initialise the crossbar with a safe value
From: Nishanth Menon
Since crossbar is s/w configurable, the initial settings of the
crossbar cannot be assumed to be sane. This implies that:
a) On initialization all un-reserved crossbars must be initialized to
a known 'safe' value.
b) When unmapping the interrupt, the safe value must be written to
ensure that the crossbar mapping matches with interrupt controller
usage.
So provide a safe value in the compatible data to map if
'0' is not safe for the platform and use it during init and unmap
Signed-off-by: Nishanth Menon
Signed-off-by: Sricharan R
Signed-off-by: Tony Lindgren
---
drivers/irqchip/irq-crossbar.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 847f6e3..287d3ce 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -44,6 +44,7 @@ struct crossbar_device {
struct crossbar_data {
const uint *irqs_unused;
const uint size;
+ const uint safe_map;
};
static struct crossbar_device *cb;
@@ -134,7 +135,7 @@ const struct irq_domain_ops routable_irq_domain_ops = {
static int __init crossbar_of_init(struct device_node *node,
const struct crossbar_data *data)
{
- int i, size, max, reserved = 0, entry;
+ int i, size, max, reserved = 0, entry, safe_map;
const __be32 *irqsr;
const int *irqsk = NULL;
@@ -212,6 +213,7 @@ static int __init crossbar_of_init(struct device_node *node,
if (data) {
irqsk = data->irqs_unused;
size = data->size;
+ safe_map = data->safe_map;
for (i = 0; i < size; i++) {
entry = irqsk[i];
@@ -222,6 +224,14 @@ static int __init crossbar_of_init(struct device_node
*node,
}
cb->irq_map[entry] = IRQ_SKIP;
}
+
+ for (i = 0; i < max; i++) {
+ if (cb->irq_map[i] == IRQ_RESERVED ||
+ cb->irq_map[i] == IRQ_SKIP)
+ continue;
+
+ cb->write(i, safe_map);
+ }
}
register_routable_domain_ops(&routable_irq_domain_ops);
@@ -241,7 +251,7 @@ err1:
/* irq number 10 cannot be used because of hw bug */
int dra_irqs_unused[] = { 10 };
struct crossbar_data cb_dra_data = { dra_irqs_unused,
-ARRAY_SIZE(dra_irqs_unused) };
+ARRAY_SIZE(dra_irqs_unused), 0 };
static const struct of_device_id crossbar_match[] __initconst = {
{ .compatible = "ti,irq-crossbar", .data = &cb_dra_data },
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 08/19] irqchip: crossbar: fix checkpatch warning
From: Nishanth Menon
remove un-necessary space in function pointer.
Fixes checkpatch warning:
WARNING: Unnecessary space before function pointer arguments
#37: FILE: drivers/irqchip/irq-crossbar.c:37:
+ void (*write) (int, int);
WARNING: Missing a blank line after declarations
+ int *register_offsets;
+ void (*write)(int, int);
WARNING: Prefer kcalloc over kzalloc with multiply
+ cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);
WARNING: Prefer kcalloc over kzalloc with multiply
+ cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
Signed-off-by: Nishanth Menon
---
drivers/irqchip/irq-crossbar.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 5da9d36..58790d4 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -34,7 +34,8 @@ struct crossbar_device {
uint *irq_map;
void __iomem *crossbar_base;
int *register_offsets;
- void (*write) (int, int);
+
+ void (*write)(int, int);
};
/**
@@ -150,7 +151,7 @@ static int __init crossbar_of_init(struct device_node *node,
goto err1;
of_property_read_u32(node, "ti,max-irqs", &max);
- cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);
+ cb->irq_map = kcalloc(max, sizeof(int), GFP_KERNEL);
if (!cb->irq_map)
goto err2;
@@ -176,7 +177,7 @@ static int __init crossbar_of_init(struct device_node *node,
}
}
- cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
+ cb->register_offsets = kcalloc(max, sizeof(int), GFP_KERNEL);
if (!cb->register_offsets)
goto err3;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 10/19] irqchip: crossbar: DRA7: Fix unused crossbar list
From: Rajendra Nayak
On DRA7 compatible IRQ crossbar, IRQ 10 default mapped to L3_APP_IRQ,
IRQ133 is default mapped to NMI pin, 139 and 140 crossbars are
unused(not routed). Mark these as unused crossbar IRQs.
Technical Reference Manual documentation update expected
DRA72x-TRMINC00067 is being used to track the update.
Reported-by: Nishanth Menon
Reported-by: Sricharan R
Reported-by: Suman Anna
Signed-off-by: Rajendra Nayak
---
drivers/irqchip/irq-crossbar.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 7d4db07..42a2e62 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -253,8 +253,8 @@ err1:
return -ENOMEM;
}
-/* irq number 10 cannot be used because of hw bug */
-static int dra_irqs_unused[] = { 10 };
+/* irq number 10,133,139 and 140 cannot be used because of hw bug */
+static int dra_irqs_unused[] = { 10 , 133, 139, 140 };
static struct crossbar_data cb_dra_data = { dra_irqs_unused,
ARRAY_SIZE(dra_irqs_unused), 0 };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 07/19] irqchip: crossbar: fix sparse warnings
From: Nishanth Menon
There is absolutely no need for crossbar driver to expose functions and
variables into global namespace. So make them all static
Fixes sparse warnings:
drivers/irqchip/irq-crossbar.c:129:29: warning: symbol
'routable_irq_domain_ops' was not declared. Should it be static?
drivers/irqchip/irq-crossbar.c:252:5: warning: symbol 'dra_irqs_unused' was not
declared. Should it be static?
drivers/irqchip/irq-crossbar.c:253:22: warning: symbol 'cb_dra_data' was not
declared. Should it be static?
drivers/irqchip/irq-crossbar.c:261:12: warning: symbol 'irqcrossbar_init' was
not declared. Should it be static?
Signed-off-by: Nishanth Menon
---
drivers/irqchip/irq-crossbar.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index c5415ae..5da9d36 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#define IRQ_FREE -1
#define IRQ_RESERVED -2
@@ -126,7 +127,7 @@ found:
return 0;
}
-const struct irq_domain_ops routable_irq_domain_ops = {
+static const struct irq_domain_ops routable_irq_domain_ops = {
.map = crossbar_domain_map,
.unmap = crossbar_domain_unmap,
.xlate = crossbar_domain_xlate
@@ -249,8 +250,8 @@ err1:
}
/* irq number 10 cannot be used because of hw bug */
-int dra_irqs_unused[] = { 10 };
-struct crossbar_data cb_dra_data = { dra_irqs_unused,
+static int dra_irqs_unused[] = { 10 };
+static struct crossbar_data cb_dra_data = { dra_irqs_unused,
ARRAY_SIZE(dra_irqs_unused), 0 };
static const struct of_device_id crossbar_match[] __initconst = {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 09/19] irqchip: crossbar: fix kerneldoc warning
From: Nishanth Menon
kernel doc style is wrong in code. fix it to squelch
kerneldoc warnings:
Warning(drivers/irqchip/irq-crossbar.c:27): missing initial short description
on line:
* struct crossbar_device: crossbar device description
Info(drivers/irqchip/irq-crossbar.c:27): Scanning doc for struct
Warning(drivers/irqchip/irq-crossbar.c:39): No description found for parameter
'write'
Warning(drivers/irqchip/irq-crossbar.c:42): missing initial short description
on line:
* struct crossbar_data: Platform specific data
Info(drivers/irqchip/irq-crossbar.c:42): Scanning doc for struct
Warning(drivers/irqchip/irq-crossbar.c:50): No description found for parameter
'safe_map'
4 warnings
Signed-off-by: Nishanth Menon
---
drivers/irqchip/irq-crossbar.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 58790d4..7d4db07 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -23,11 +23,13 @@
#define IRQ_SKIP -3
#define GIC_IRQ_START 32
-/*
+/**
+ * struct crossbar_device - crossbar device descriptio
* @int_max: maximum number of supported interrupts
* @irq_map: array of interrupts to crossbar number mapping
* @crossbar_base: crossbar base address
* @register_offsets: offsets for each irq number
+ * @write: register write function pointer
*/
struct crossbar_device {
uint int_max;
@@ -39,9 +41,10 @@ struct crossbar_device {
};
/**
- * struct crossbar_data: Platform specific data
+ * struct crossbar_data - Platform specific data
* @irqs_unused: array of irqs that cannot be used because of hw erratas
* @size: size of the irqs_unused array
+ * @safe_map: safe value to write to crossbar register
*/
struct crossbar_data {
const uint *irqs_unused;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 14/19] irqchip: crossbar: set cb pointer to null in case of error
If crossbar_of_init returns with a error, then set the cb pointer to null. Signed-off-by: Sricharan R --- drivers/irqchip/irq-crossbar.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c index cf0d79f..5f3e75a 100644 --- a/drivers/irqchip/irq-crossbar.c +++ b/drivers/irqchip/irq-crossbar.c @@ -259,6 +259,8 @@ err_base: iounmap(cb->crossbar_base); err_cb: kfree(cb); + + cb = NULL; return ret; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 15/19] irqchip: crossbar: Add kerneldoc for crossbar_domain_unmap callback
The crossbar_domain_map/unmap callbacks need not be called same number
of times for a particular irq. But still use counting is not needed
here, because unmap(irq) gets called when irq_desc(irq) is disposed.
After this the irq is anyways unusable and have to mapped again.
Adding the above kerneldoc for unmap callback clarity.
Signed-off-by: Sricharan R
---
drivers/irqchip/irq-crossbar.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 5f3e75a..2a73a66 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -101,6 +101,16 @@ static int crossbar_domain_map(struct irq_domain *d,
unsigned int irq,
return 0;
}
+/**
+ * crossbar_domain_unmap - unmap a crossbar<->irq connection
+ * @d: domain of irq to unmap
+ * @irq: virq number
+ *
+ * The map/unmap callbacks need not be called same number of times for
+ * a particular irq. But still use counting is not needed here, because
+ * unmap(irq) gets called when irq_desc(irq) is disposed. After this the
+ * irq is anyways unusuable and have to be mapped again.
+ */
static void crossbar_domain_unmap(struct irq_domain *d, unsigned int irq)
{
irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 11/19] irqchip: crossbar: fix memory leak incase of invalid entry
From: Nishanth Menon
When the provided unused skip list entry is greater than max irqs
possible, we go to err3, but we fail to free register_offsets,
should have returned to err4 instead which ensures that allocated
register_offsets are freed as well.
Signed-off-by: Nishanth Menon
---
drivers/irqchip/irq-crossbar.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 42a2e62..fea3e5d 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -225,7 +225,7 @@ static int __init crossbar_of_init(struct device_node *node,
if (entry > max) {
pr_err("Invalid skip entry\n");
- goto err3;
+ goto err4;
}
cb->irq_map[entry] = IRQ_SKIP;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 12/19] irqchip: crossbar: return proper error value
From: Nishanth Menon
crossbar_of_init always returns -ENOMEM in case of errors, return proper
error results in case of failures.
Signed-off-by: Nishanth Menon
---
drivers/irqchip/irq-crossbar.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index fea3e5d..524e6e9 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -140,20 +140,26 @@ static const struct irq_domain_ops
routable_irq_domain_ops = {
static int __init crossbar_of_init(struct device_node *node,
const struct crossbar_data *data)
{
- int i, size, max, reserved = 0, entry, safe_map;
+ int i, size, max = 0, reserved = 0, entry, safe_map;
const __be32 *irqsr;
const int *irqsk = NULL;
+ int ret = -ENOMEM;
cb = kzalloc(sizeof(*cb), GFP_KERNEL);
if (!cb)
- return -ENOMEM;
+ return ret;
cb->crossbar_base = of_iomap(node, 0);
if (!cb->crossbar_base)
goto err1;
of_property_read_u32(node, "ti,max-irqs", &max);
+ if (!max) {
+ pr_err("missing 'ti,max-irqs' property\n");
+ ret = -EINVAL;
+ goto err2;
+ }
cb->irq_map = kcalloc(max, sizeof(int), GFP_KERNEL);
if (!cb->irq_map)
goto err2;
@@ -174,6 +180,7 @@ static int __init crossbar_of_init(struct device_node *node,
i, &entry);
if (entry > max) {
pr_err("Invalid reserved entry\n");
+ ret = -EINVAL;
goto err3;
}
cb->irq_map[entry] = IRQ_RESERVED;
@@ -198,6 +205,7 @@ static int __init crossbar_of_init(struct device_node *node,
break;
default:
pr_err("Invalid reg-size property\n");
+ ret = -EINVAL;
goto err4;
break;
}
@@ -225,6 +233,7 @@ static int __init crossbar_of_init(struct device_node *node,
if (entry > max) {
pr_err("Invalid skip entry\n");
+ ret = -EINVAL;
goto err4;
}
cb->irq_map[entry] = IRQ_SKIP;
@@ -250,7 +259,7 @@ err2:
iounmap(cb->crossbar_base);
err1:
kfree(cb);
- return -ENOMEM;
+ return ret;
}
/* irq number 10,133,139 and 140 cannot be used because of hw bug */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 16/19] irqchip: crossbar: introduce ti,max-crossbar-sources to identify valid crossbar mapping
From: Nishanth Menon
Currently we attempt to map any crossbar value to an IRQ, however,
this is not correct from hardware perspective. There is a max crossbar
event number upto which hardware supports. So describe the same in
device tree using 'ti,max-crossbar-sources' property and use it to
validate requests.
Signed-off-by: Nishanth Menon
---
.../devicetree/bindings/arm/omap/crossbar.txt |2 ++
drivers/irqchip/irq-crossbar.c | 21 ++--
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
index fb88585..6d2e2f5 100644
--- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -10,6 +10,7 @@ Required properties:
- compatible : Should be "ti,irq-crossbar"
- reg: Base address and the size of the crossbar registers.
- ti,max-irqs: Total number of irqs available at the interrupt controller.
+- ti,max-crossbar-sources: Maximum number of crossbar sources that can be
routed.
- ti,reg-size: Size of a individual register in bytes. Every individual
register is assumed to be of same size. Valid sizes are 1, 2, 4.
- ti,irqs-reserved: List of the reserved irq lines that are not muxed using
@@ -22,6 +23,7 @@ Examples:
compatible = "ti,irq-crossbar";
reg = <0x4a002a48 0x130>;
ti,max-irqs = <160>;
+ ti,max-crossbar-sources = <400>;
ti,reg-size = <2>;
ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
};
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 2a73a66..cf69c4d 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -26,6 +26,7 @@
/**
* struct crossbar_device - crossbar device descriptio
* @int_max: maximum number of supported interrupts
+ * @max_crossbar_sources: Maximum number of crossbar sources
* @irq_map: array of interrupts to crossbar number mapping
* @crossbar_base: crossbar base address
* @register_offsets: offsets for each irq number
@@ -33,6 +34,7 @@
*/
struct crossbar_device {
uint int_max;
+ uint max_crossbar_sources;
uint *irq_map;
void __iomem *crossbar_base;
int *register_offsets;
@@ -126,12 +128,19 @@ static int crossbar_domain_xlate(struct irq_domain *d,
unsigned int *out_type)
{
int ret;
+ int req_num = intspec[1];
- ret = get_prev_map_irq(intspec[1]);
+ if (req_num >= cb->max_crossbar_sources) {
+ pr_err("%s: requested crossbar number %d > max %d\n",
+ __func__, req_num, cb->max_crossbar_sources);
+ return -EINVAL;
+ }
+
+ ret = get_prev_map_irq(req_num);
if (ret >= 0)
goto found;
- ret = allocate_free_irq(intspec[1]);
+ ret = allocate_free_irq(req_num);
if (ret < 0)
return ret;
@@ -164,6 +173,14 @@ static int __init crossbar_of_init(struct device_node
*node,
if (!cb->crossbar_base)
goto err_cb;
+ of_property_read_u32(node, "ti,max-crossbar-sources",
+&cb->max_crossbar_sources);
+ if (!cb->max_crossbar_sources) {
+ pr_err("missing 'ti,max-crossbar-sources' property\n");
+ ret = -EINVAL;
+ goto err_base;
+ }
+
of_property_read_u32(node, "ti,max-irqs", &max);
if (!max) {
pr_err("missing 'ti,max-irqs' property\n");
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 17/19] irqchip: crossbar: introduce centralized check for crossbar write
From: Nishanth Menon
This is a basic check to ensure that crossbar register needs to be
written. This ensures that we have a common check which is used in
both map and unmap logic.
Signed-off-by: Nishanth Menon
---
drivers/irqchip/irq-crossbar.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index cf69c4d..745ad0a 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -96,10 +96,20 @@ static inline int allocate_free_irq(int cb_no)
return -ENODEV;
}
+static inline bool needs_crossbar_write(irq_hw_number_t hw)
+{
+ if (hw > GIC_IRQ_START)
+ return true;
+
+ return false;
+}
+
static int crossbar_domain_map(struct irq_domain *d, unsigned int irq,
irq_hw_number_t hw)
{
- cb->write(hw - GIC_IRQ_START, cb->irq_map[hw - GIC_IRQ_START]);
+ if (needs_crossbar_write(hw))
+ cb->write(hw - GIC_IRQ_START, cb->irq_map[hw - GIC_IRQ_START]);
+
return 0;
}
@@ -117,7 +127,7 @@ static void crossbar_domain_unmap(struct irq_domain *d,
unsigned int irq)
{
irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
- if (hw > GIC_IRQ_START)
+ if (needs_crossbar_write(hw))
cb->irq_map[hw - GIC_IRQ_START] = IRQ_FREE;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 13/19] irqchip: crossbar: change the goto naming
From: Nishanth Menon
Using err1,2,3,4 etc makes it hard to ensure a new exit path in the
middle will not result in spurious changes, so rename the error paths
as per the function it does.
Signed-off-by: Nishanth Menon
---
drivers/irqchip/irq-crossbar.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 524e6e9..cf0d79f 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -152,17 +152,17 @@ static int __init crossbar_of_init(struct device_node
*node,
cb->crossbar_base = of_iomap(node, 0);
if (!cb->crossbar_base)
- goto err1;
+ goto err_cb;
of_property_read_u32(node, "ti,max-irqs", &max);
if (!max) {
pr_err("missing 'ti,max-irqs' property\n");
ret = -EINVAL;
- goto err2;
+ goto err_base;
}
cb->irq_map = kcalloc(max, sizeof(int), GFP_KERNEL);
if (!cb->irq_map)
- goto err2;
+ goto err_base;
cb->int_max = max;
@@ -181,7 +181,7 @@ static int __init crossbar_of_init(struct device_node *node,
if (entry > max) {
pr_err("Invalid reserved entry\n");
ret = -EINVAL;
- goto err3;
+ goto err_irq_map;
}
cb->irq_map[entry] = IRQ_RESERVED;
}
@@ -189,7 +189,7 @@ static int __init crossbar_of_init(struct device_node *node,
cb->register_offsets = kcalloc(max, sizeof(int), GFP_KERNEL);
if (!cb->register_offsets)
- goto err3;
+ goto err_irq_map;
of_property_read_u32(node, "ti,reg-size", &size);
@@ -206,7 +206,7 @@ static int __init crossbar_of_init(struct device_node *node,
default:
pr_err("Invalid reg-size property\n");
ret = -EINVAL;
- goto err4;
+ goto err_reg_offset;
break;
}
@@ -234,7 +234,7 @@ static int __init crossbar_of_init(struct device_node *node,
if (entry > max) {
pr_err("Invalid skip entry\n");
ret = -EINVAL;
- goto err4;
+ goto err_reg_offset;
}
cb->irq_map[entry] = IRQ_SKIP;
}
@@ -251,13 +251,13 @@ static int __init crossbar_of_init(struct device_node
*node,
register_routable_domain_ops(&routable_irq_domain_ops);
return 0;
-err4:
+err_reg_offset:
kfree(cb->register_offsets);
-err3:
+err_irq_map:
kfree(cb->irq_map);
-err2:
+err_base:
iounmap(cb->crossbar_base);
-err1:
+err_cb:
kfree(cb);
return ret;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 18/19] Documentation: dt: OMAP: crossbar: add description for interrupt consumer
From: Nishanth Menon
The current crossbar description does not include the description
required for the consumer of the crossbar, a.k.a devices whoes events
pass through the crossbar into the GIC interrupt controller.
So, provide documentation for the same.
Signed-off-by: Nishanth Menon
---
.../devicetree/bindings/arm/omap/crossbar.txt | 17 +
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
index 6d2e2f5..816d11b 100644
--- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -27,3 +27,20 @@ Examples:
ti,reg-size = <2>;
ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
};
+
+Consumer:
+
+See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
+Documentation/devicetree/bindings/arm/gic.txt for further details.
+
+An interrupt consumer on an SoC using crossbar will use:
+ interrupts =
+request number shall be between 0 to that described by
+"ti,max-crossbar-sources"
+
+Example:
+ device_x@0x4a023000 {
+ /* Crossbar 8 used */
+ interrupts = ;
+ ...
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 02/19] irqchip: crossbar: check for premapped crossbar before allocating
From: Nishanth Menon
If irq_of_parse_and_map is executed twice, the same crossbar is mapped to two
different GIC interrupts. This is completely undesirable. Instead, check
if the requested crossbar event is pre-allocated and provide that GIC
mapping back to caller if already allocated.
Signed-off-by: Nishanth Menon
Signed-off-by: Sricharan R
Signed-off-by: Tony Lindgren
---
drivers/irqchip/irq-crossbar.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 20105bc..51d4b87 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -51,6 +51,17 @@ static inline void crossbar_writeb(int irq_no, int cb_no)
writeb(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
}
+static inline int get_prev_map_irq(int cb_no)
+{
+ int i;
+
+ for (i = 0; i < cb->int_max; i++)
+ if (cb->irq_map[i] == cb_no)
+ return i;
+
+ return -ENODEV;
+}
+
static inline int allocate_free_irq(int cb_no)
{
int i;
@@ -88,11 +99,16 @@ static int crossbar_domain_xlate(struct irq_domain *d,
{
unsigned long ret;
+ ret = get_prev_map_irq(intspec[1]);
+ if (!IS_ERR_VALUE(ret))
+ goto found;
+
ret = allocate_free_irq(intspec[1]);
if (IS_ERR_VALUE(ret))
return ret;
+found:
*out_hwirq = ret + GIC_IRQ_START;
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 19/19] irqchip: crossbar allow for quirky hardware with direct hardwiring of GIC
From: Nishanth Menon
On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10, 131,
132, 133 are direct wired to hardware blocks bypassing crossbar.
This quirky implementation is *NOT* supposed to be the expectation
of crossbar hardware usage. However, these are already marked in our
description of the hardware with SKIP and RESERVED where appropriate.
Unfortunately, we need to be able to refer to these hardwired IRQs.
So, to request these, crossbar driver can use the existing information
from it's table that these SKIP/RESERVED maps are direct wired sources
and generic allocation/programming of crossbar should be avoided.
Signed-off-by: Nishanth Menon
---
.../devicetree/bindings/arm/omap/crossbar.txt | 12 ++--
drivers/irqchip/irq-crossbar.c | 20 ++--
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
index 816d11b..7476d9b 100644
--- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -35,8 +35,10 @@ Documentation/devicetree/bindings/arm/gic.txt for further
details.
An interrupt consumer on an SoC using crossbar will use:
interrupts =
-request number shall be between 0 to that described by
-"ti,max-crossbar-sources"
+When the request number is between 0 to that described by
+"ti,max-crossbar-sources", it is assumed to be a crossbar mapping. If the
+request_number is greater than "ti,max-crossbar-sources", then it is mapped as
a
+quirky hardware mapping direct to GIC.
Example:
device_x@0x4a023000 {
@@ -44,3 +46,9 @@ Example:
interrupts = ;
...
};
+
+ device_y@0x4a033000 {
+ /* Direct mapped GIC SPI 1 used */
+ interrupts = ;
+ ...
+ };
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 745ad0a..2b61bbb 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -98,8 +98,13 @@ static inline int allocate_free_irq(int cb_no)
static inline bool needs_crossbar_write(irq_hw_number_t hw)
{
- if (hw > GIC_IRQ_START)
- return true;
+ int cb_no;
+
+ if (hw > GIC_IRQ_START) {
+ cb_no = cb->irq_map[hw - GIC_IRQ_START];
+ if (cb_no != IRQ_RESERVED && cb_no != IRQ_SKIP)
+ return true;
+ }
return false;
}
@@ -139,8 +144,19 @@ static int crossbar_domain_xlate(struct irq_domain *d,
{
int ret;
int req_num = intspec[1];
+ int direct_map_num;
if (req_num >= cb->max_crossbar_sources) {
+ direct_map_num = req_num - cb->max_crossbar_sources;
+ if (direct_map_num < cb->int_max) {
+ ret = cb->irq_map[direct_map_num];
+ if (ret == IRQ_RESERVED || ret == IRQ_SKIP) {
+ /* We use the interrupt num as h/w irq num */
+ ret = direct_map_num;
+ goto found;
+ }
+ }
+
pr_err("%s: requested crossbar number %d > max %d\n",
__func__, req_num, cb->max_crossbar_sources);
return -EINVAL;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 01/19] irqchip: crossbar: dont use '0' to mark reserved interrupts
From: Nishanth Menon
Today '0' is actually reserved, but may not be the same in the future.
So, use a flag to mark the GIC interrupts that are reserved.
Signed-off-by: Nishanth Menon
Signed-off-by: Sricharan R
Signed-off-by: Tony Lindgren
---
drivers/irqchip/irq-crossbar.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 3d15d16..20105bc 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -17,6 +17,7 @@
#include
#define IRQ_FREE -1
+#define IRQ_RESERVED -2
#define GIC_IRQ_START 32
/*
@@ -139,7 +140,7 @@ static int __init crossbar_of_init(struct device_node *node)
pr_err("Invalid reserved entry\n");
goto err3;
}
- cb->irq_map[entry] = 0;
+ cb->irq_map[entry] = IRQ_RESERVED;
}
}
@@ -170,7 +171,7 @@ static int __init crossbar_of_init(struct device_node *node)
* reserved irqs. so find and store the offsets once.
*/
for (i = 0; i < max; i++) {
- if (!cb->irq_map[i])
+ if (cb->irq_map[i] == IRQ_RESERVED)
continue;
cb->register_offsets[i] = reserved;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 0/2] ARM: OMAP2+: remove DMA interrupt if DT provided
This series removes the DMA interrupt registration if DT provides interrupts, so we have no need for hwmod provided interrupt number. This is a pre-req for crossbar migration as DMA is the last driver to use interrupt definition from hwmod. [V2] Rebased on 3.15 mainline Nishanth Menon (2): ARM: OMAP2+: DMA: remove requirement of irq for platform-dma driver ARM: DRA7: hwmod: remove interrupts for DMA arch/arm/mach-omap2/dma.c |3 +++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c |9 - arch/arm/plat-omap/dma.c |5 +++-- include/linux/omap-dma.h |1 + 4 files changed, 7 insertions(+), 11 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 2/2] ARM: DRA7: hwmod: remove interrupts for DMA
From: Nishanth Menon
DMA interrupts are now available in of, and the definitions are
duplicates in hwmod. This prevents us from dynamically allocating
interrupt resources for dma from devicetree.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c |9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 20b4398..31fd260 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -343,19 +343,10 @@ static struct omap_dma_dev_attr dma_dev_attr = {
};
/* dma_system */
-static struct omap_hwmod_irq_info dra7xx_dma_system_irqs[] = {
- { .name = "0", .irq = 12 + DRA7XX_IRQ_GIC_START },
- { .name = "1", .irq = 13 + DRA7XX_IRQ_GIC_START },
- { .name = "2", .irq = 14 + DRA7XX_IRQ_GIC_START },
- { .name = "3", .irq = 15 + DRA7XX_IRQ_GIC_START },
- { .irq = -1 }
-};
-
static struct omap_hwmod dra7xx_dma_system_hwmod = {
.name = "dma_system",
.class = &dra7xx_dma_hwmod_class,
.clkdm_name = "dma_clkdm",
- .mpu_irqs = dra7xx_dma_system_irqs,
.main_clk = "l3_iclk_div",
.prcm = {
.omap4 = {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/2] ARM: OMAP2+: DMA: remove requirement of irq for platform-dma driver
From: Nishanth Menon
we have currently 2 DMA drivers that try to co-exist.
drivers/dma/omap-dma.c which registers it's own IRQ and is device tree
aware and uses arch/arm/plat-omap/dma.c instance created by
arch/arm/mach-omap2/dma.c to maintain channel usage (omap_request_dma).
Currently both try to register interrupts and mach-omap2/plat-omap dma.c
attempts to use the IRQ number registered by hwmod to register it's own
interrupt handler.
Now, there is no reasonable way of static allocating DMA irq in GIC
SPI when we use crossbar. However, since the dma_chan structure is
freed as a result of IRQ not being present due to devm allocation,
maintaining information of channel by platform code fails at a later
point in time when that region of memory is reused.
So, if hwmod does not indicate an IRQ number, then, assume that
dma-engine will take care of the interrupt handling.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/dma.c |3 +++
arch/arm/plat-omap/dma.c |5 +++--
include/linux/omap-dma.h |1 +
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index a6d2cf1..e1a56d8 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -259,6 +259,9 @@ static int __init omap2_system_dma_init_dev(struct
omap_hwmod *oh, void *unused)
if (cpu_is_omap34xx() && (omap_type() != OMAP2_DEVICE_TYPE_GP))
d->dev_caps |= HS_CHANNELS_RESERVED;
+ if (platform_get_irq_byname(pdev, "0") < 0)
+ d->dev_caps |= DMA_ENGINE_HANDLE_IRQ;
+
/* Check the capabilities register for descriptor loading feature */
if (dma_read(CAPS_0, 0) & DMA_HAS_DESCRIPTOR_CAPS)
dma_common_ch_end = CCDN;
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index b5608b1..7aae0e5 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2100,7 +2100,7 @@ static int omap_system_dma_probe(struct platform_device
*pdev)
omap_dma_set_global_params(DMA_DEFAULT_ARB_RATE,
DMA_DEFAULT_FIFO_DEPTH, 0);
- if (dma_omap2plus()) {
+ if (dma_omap2plus() && !(d->dev_caps & DMA_ENGINE_HANDLE_IRQ)) {
strcpy(irq_name, "0");
dma_irq = platform_get_irq_byname(pdev, irq_name);
if (dma_irq < 0) {
@@ -2145,7 +2145,8 @@ static int omap_system_dma_remove(struct platform_device
*pdev)
char irq_name[4];
strcpy(irq_name, "0");
dma_irq = platform_get_irq_byname(pdev, irq_name);
- remove_irq(dma_irq, &omap24xx_dma_irq);
+ if (dma_irq >= 0)
+ remove_irq(dma_irq, &omap24xx_dma_irq);
} else {
int irq_rel = 0;
for ( ; irq_rel < dma_chan_count; irq_rel++) {
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 88e6ea4..6f06f8b 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -130,6 +130,7 @@
#define IS_WORD_16 BIT(0xd)
#define ENABLE_16XX_MODE BIT(0xe)
#define HS_CHANNELS_RESERVED BIT(0xf)
+#define DMA_ENGINE_HANDLE_IRQ BIT(0x10)
/* Defines for DMA Capabilities */
#define DMA_HAS_TRANSPARENT_CAPS (0x1 << 18)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
VIGTIG INFO
Du har overskredet opbevaring grænse på din postkasse. Du vil ikke være i stand til at sende eller modtage ny post, indtil du opgraderer din email kvote. klik / Kopier nedenstående link og udfylde formularen for at opgradere din konto. www.formstack.com/forms/?1765597-1sZTBpywmm systemadministrator 192.168.0.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] randconfig fixes for mmc
On 5 June 2014 23:14, Arnd Bergmann wrote: > Hi Chris, Ulf, > > These are small fixes from my randconfig testing, almost all for > older bugs, please apply to a tree you see appropriate. Thanks Arnd! Applied for fixes. Kind regards Uffe > > Arnd > > Arnd Bergmann (4): > mmc: atmel-mci: incude asm/cacheclush.h > mmc: mvsdio: avoid compiler warning > mmc: omap: don't select TPS65010 > mmc: simplify SDHCI Kconfig dependencies > > drivers/mmc/host/Kconfig | 10 -- > drivers/mmc/host/atmel-mci.c | 1 + > drivers/mmc/host/mvsdio.c| 2 +- > 3 files changed, 6 insertions(+), 7 deletions(-) > > -- > 1.8.3.2 > > Cc: Ludovic Desroches > Cc: Nicolas Pitre > Cc: Chris Ball > Cc: Thomas Petazzoni > Cc: Jason Cooper > Cc: Andrew Lunn > Cc: linux-...@vger.kernel.org > Cc: linux-omap@vger.kernel.org > Cc: Jarkko Nikula -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] mfd: Immutable branch between MFD and OMAP, due for v3.16
On Thu, 12 Jun 2014, Tony Lindgren wrote:
> * Lee Jones [140612 00:48]:
> > On Wed, 11 Jun 2014, Tony Lindgren wrote:
> >
> > > * Lee Jones [140603 01:08]:
> > > > On Mon, 02 Jun 2014, Tony Lindgren wrote:
> > > > > * Tony Lindgren [140528 11:11]:
> > > > > > * Lee Jones [140528 00:14]:
> > > > > > > Thanks Tony, here's the pull-request:
> > > > > > >
> > > > > > > The following changes since commit
> > > > > > > 455c6fdbd219161bd09b1165f11699d6d73de11c:
> > > > > > >
> > > > > > > Linux 3.14 (2014-03-30 20:40:15 -0700)
> > > > > > >
> > > > > > > are available in the git repository at:
> > > > > > >
> > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git
> > > > > > > tags/mfd-omap-v3.16-1
> > > > > > >
> > > > > > > for you to fetch changes up to
> > > > > > > 43fef47f94a1ae46fb2720dada32fa3b5547bee2:
> > > > > > >
> > > > > > > mfd: twl4030-power: Add a configuration to turn off oscillator
> > > > > > > during off-idle (2014-05-28 08:06:18 +0100)
> > > > > > >
> > > > > > >
> > > > > > > Second immutable branch between MFD and OMAP due for the v3.16
> > > > > > > merge window.
> > > > > >
> > > > > > Thanks a lot, this will make it easier for me to chase down
> > > > > > potential
> > > > > > PM related regressions ;) I'm merging this for testing only into the
> > > > > > linux-omap master branch, no need for me to include it into any
> > > > > > of my upstream heading branches.
> > > > >
> > > > > Lee, I'm not seeing this in linux next, did you maybe forget to merge
> > > > > it into the MFD tree?
> > > >
> > > > I didn't forget, but I didn't do it either. :)
> > > >
> > > > I have re-merged all of the IBs this morning, so should be in -next
> > > > by tomorrow.
> > >
> > > Still not seeing this branch being merged..
> >
> > Oh crap, I see what's happened and it's completely my fault.
> >
> > If you read the final merge commit carefully:
> >
> > 28fee3f: ("Merge branches 'ib-from-asoc-3.16', 'ib-from-pm-3.16',
> > 'ib-from-regulator-3.16', 'ib-mfd-gpio-3.16' and
> > 'ib-mfd-mmc-memstick-3.16', tags 'ib-mfd-extcon-3.16',
> > 'ib-mfd-omap-3.16' and 'ib-mfd-regulator-3.16' into
> > ibs-for-mfd-merged")
> >
> > I appear to have a _branch_ AND a _tag_ called ib-mfd-omap-3.16 and it
> > looks like Git has taken the tag as a preference. heads/ib-mfd-omap-3.16
> > is actually at tag/ib-mfd-omap-3.16-1 (notice the appended '-1'),
> > which contains your most recent patches. Since I created the MFD-OMAP
> > shared branch I have changed the naming convention to avoid this sort
> > of ambiguity. I'll send a second MFD pull-request to Linus today.
>
> Heh OK yeah I've hit that also at some point :)
>
> > Sorry Tony.
>
> No problem, good to hear you got it figured out.
Pull-request sent. Hopefully it's sorted now.
If there are any more issues I'll sort them out as they appear, but I
may be a little slower than usual as I'm currently on holiday in Spain.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] gpio: of: Allow -gpio suffix for property names
On Tue, Jun 3, 2014 at 1:14 AM, Tony Lindgren wrote: > Looks like something like below fixes the issue. > > Regards, > > Tony > > 8< --- > From: Tony Lindgren > Date: Mon, 2 Jun 2014 16:13:46 -0700 > Subject: [PATCH] gpio: of: Fix handling for deferred probe for -gpio suffix > > Commit dd34c37aa3e (gpio: of: Allow -gpio suffix for property names) > added parsing for both -gpio and -gpios suffix but also changed > the handling for deferred probe unintentionally. Because of the > looping the second name will now return -ENOENT instead of > -EPROBE_DEFER. Fix the issue by breaking out of the loop if > -EPROBE_DEFER is encountered. > > Signed-off-by: Tony Lindgren Patch applied for fixes with Thierry's Reveiwed-by tag. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] mfd: Immutable branch between MFD and OMAP, due for v3.16
* Lee Jones [140612 00:48]:
> On Wed, 11 Jun 2014, Tony Lindgren wrote:
>
> > * Lee Jones [140603 01:08]:
> > > On Mon, 02 Jun 2014, Tony Lindgren wrote:
> > > > * Tony Lindgren [140528 11:11]:
> > > > > * Lee Jones [140528 00:14]:
> > > > > > Thanks Tony, here's the pull-request:
> > > > > >
> > > > > > The following changes since commit
> > > > > > 455c6fdbd219161bd09b1165f11699d6d73de11c:
> > > > > >
> > > > > > Linux 3.14 (2014-03-30 20:40:15 -0700)
> > > > > >
> > > > > > are available in the git repository at:
> > > > > >
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git
> > > > > > tags/mfd-omap-v3.16-1
> > > > > >
> > > > > > for you to fetch changes up to
> > > > > > 43fef47f94a1ae46fb2720dada32fa3b5547bee2:
> > > > > >
> > > > > > mfd: twl4030-power: Add a configuration to turn off oscillator
> > > > > > during off-idle (2014-05-28 08:06:18 +0100)
> > > > > >
> > > > > >
> > > > > > Second immutable branch between MFD and OMAP due for the v3.16
> > > > > > merge window.
> > > > >
> > > > > Thanks a lot, this will make it easier for me to chase down potential
> > > > > PM related regressions ;) I'm merging this for testing only into the
> > > > > linux-omap master branch, no need for me to include it into any
> > > > > of my upstream heading branches.
> > > >
> > > > Lee, I'm not seeing this in linux next, did you maybe forget to merge
> > > > it into the MFD tree?
> > >
> > > I didn't forget, but I didn't do it either. :)
> > >
> > > I have re-merged all of the IBs this morning, so should be in -next
> > > by tomorrow.
> >
> > Still not seeing this branch being merged..
>
> Oh crap, I see what's happened and it's completely my fault.
>
> If you read the final merge commit carefully:
>
> 28fee3f: ("Merge branches 'ib-from-asoc-3.16', 'ib-from-pm-3.16',
> 'ib-from-regulator-3.16', 'ib-mfd-gpio-3.16' and
> 'ib-mfd-mmc-memstick-3.16', tags 'ib-mfd-extcon-3.16',
> 'ib-mfd-omap-3.16' and 'ib-mfd-regulator-3.16' into
> ibs-for-mfd-merged")
>
> I appear to have a _branch_ AND a _tag_ called ib-mfd-omap-3.16 and it
> looks like Git has taken the tag as a preference. heads/ib-mfd-omap-3.16
> is actually at tag/ib-mfd-omap-3.16-1 (notice the appended '-1'),
> which contains your most recent patches. Since I created the MFD-OMAP
> shared branch I have changed the naming convention to avoid this sort
> of ambiguity. I'll send a second MFD pull-request to Linus today.
Heh OK yeah I've hit that also at some point :)
> Sorry Tony.
No problem, good to hear you got it figured out.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] mfd: Immutable branch between MFD and OMAP, due for v3.16
On Wed, 11 Jun 2014, Tony Lindgren wrote:
> * Lee Jones [140603 01:08]:
> > On Mon, 02 Jun 2014, Tony Lindgren wrote:
> > > * Tony Lindgren [140528 11:11]:
> > > > * Lee Jones [140528 00:14]:
> > > > > Thanks Tony, here's the pull-request:
> > > > >
> > > > > The following changes since commit
> > > > > 455c6fdbd219161bd09b1165f11699d6d73de11c:
> > > > >
> > > > > Linux 3.14 (2014-03-30 20:40:15 -0700)
> > > > >
> > > > > are available in the git repository at:
> > > > >
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git
> > > > > tags/mfd-omap-v3.16-1
> > > > >
> > > > > for you to fetch changes up to
> > > > > 43fef47f94a1ae46fb2720dada32fa3b5547bee2:
> > > > >
> > > > > mfd: twl4030-power: Add a configuration to turn off oscillator
> > > > > during off-idle (2014-05-28 08:06:18 +0100)
> > > > >
> > > > >
> > > > > Second immutable branch between MFD and OMAP due for the v3.16 merge
> > > > > window.
> > > >
> > > > Thanks a lot, this will make it easier for me to chase down potential
> > > > PM related regressions ;) I'm merging this for testing only into the
> > > > linux-omap master branch, no need for me to include it into any
> > > > of my upstream heading branches.
> > >
> > > Lee, I'm not seeing this in linux next, did you maybe forget to merge
> > > it into the MFD tree?
> >
> > I didn't forget, but I didn't do it either. :)
> >
> > I have re-merged all of the IBs this morning, so should be in -next
> > by tomorrow.
>
> Still not seeing this branch being merged..
Oh crap, I see what's happened and it's completely my fault.
If you read the final merge commit carefully:
28fee3f: ("Merge branches 'ib-from-asoc-3.16', 'ib-from-pm-3.16',
'ib-from-regulator-3.16', 'ib-mfd-gpio-3.16' and
'ib-mfd-mmc-memstick-3.16', tags 'ib-mfd-extcon-3.16',
'ib-mfd-omap-3.16' and 'ib-mfd-regulator-3.16' into
ibs-for-mfd-merged")
I appear to have a _branch_ AND a _tag_ called ib-mfd-omap-3.16 and it
looks like Git has taken the tag as a preference. heads/ib-mfd-omap-3.16
is actually at tag/ib-mfd-omap-3.16-1 (notice the appended '-1'),
which contains your most recent patches. Since I created the MFD-OMAP
shared branch I have changed the naming convention to avoid this sort
of ambiguity. I'll send a second MFD pull-request to Linus today.
Sorry Tony.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
