Re: [PATCHv4 0/7] omap hwspinlock dt support
On 03/18/2014 08:35 AM, Ohad Ben-Cohen wrote: Hi Suman, On Tue, Mar 18, 2014 at 1:46 AM, Suman Anna s-a...@ti.com wrote: So far, we have not come across multiple controllers. I see your point, and I think this also depends on the semantics of how you exchange the lock id number. The agreement at the moment is on base_ids across multiple SoC components. If the semantics involve exchanging the controller instance, for example, then we might get away with it. But that probably involves adding additional helpers to retrieve controller instance in addition to lock number, or some other similar functions. Yes, this could be done too, but I agree it is less simple with no real win. Sorry, I should have rephrased it better - by order, I meant the inherent order between board early code and other drivers. With DT, we cannot guarantee that right, as specific locks are requested from drivers. Yeah. Understood. And we may have to assign the client association with a lock as well. These are core changes that were actually not needed in the non-DT case due to the inherent order as stated above. So, are you suggesting that we add one more property to the controller node to mark which are reserved, or rely on constructing this through DT tree parsing? I guess this is a question to the DT folks; both approaches work from hwspinlock perspective. In the past Arnd Benoit and myself were happy with adding one more property to the controller node, but this might be somewhat error prone as it leaves room for mistakes - developers can add hwlock phandles and forget to update the reserved property in the controller node. Ohad, I agree that this is the most simplest form (either a reserved number starting from base, or a reserved range - I prefer the first). The developer errors can be restricted by having the of_hwspin_lock_request_specific() return an error if anything outside this reserved range is requested. Mark, Kumar, Any recommendations/objections on this problem/approach? I also have to bring back the hwlock-base-id property (dropped in v3) for registration purposes, so that the registration does not change based on the probe order of the multiple controller nodes. regards Suman -- 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: [PATCHv4 0/7] omap hwspinlock dt support
Hi Suman, On Tue, Mar 18, 2014 at 1:46 AM, Suman Anna s-a...@ti.com wrote: So far, we have not come across multiple controllers. I see your point, and I think this also depends on the semantics of how you exchange the lock id number. The agreement at the moment is on base_ids across multiple SoC components. If the semantics involve exchanging the controller instance, for example, then we might get away with it. But that probably involves adding additional helpers to retrieve controller instance in addition to lock number, or some other similar functions. Yes, this could be done too, but I agree it is less simple with no real win. Sorry, I should have rephrased it better - by order, I meant the inherent order between board early code and other drivers. With DT, we cannot guarantee that right, as specific locks are requested from drivers. Yeah. Understood. And we may have to assign the client association with a lock as well. These are core changes that were actually not needed in the non-DT case due to the inherent order as stated above. So, are you suggesting that we add one more property to the controller node to mark which are reserved, or rely on constructing this through DT tree parsing? I guess this is a question to the DT folks; both approaches work from hwspinlock perspective. In the past Arnd Benoit and myself were happy with adding one more property to the controller node, but this might be somewhat error prone as it leaves room for mistakes - developers can add hwlock phandles and forget to update the reserved property in the controller node. Thanks, Ohad. -- 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: [PATCHv4 0/7] omap hwspinlock dt support
Hi Suman, On Sat, Mar 15, 2014 at 1:58 AM, Suman Anna s-a...@ti.com wrote: The series doesn't change the semantics of hwspinlock registration or adds a new OF controller registration function. Implementations would still need to register a controller using a base_id and number of locks. The series rather adds a DT-friendly function _ONLY_ for requesting a specific hwlock, and there are no restrictions on the args specifier being relative id numbers. Though this is what the simple default xlate helper does (most common usage), the added xlate ops and #hwlock-cells should allow individual implementation drivers to adjust any variations, and return a relative lock w.r.t its registered base_id, as this is how a lock gets registered in the first place. I might be missing something, but why can't we have the specifier+base_id be the hwlock id and then we can entirely drop most of the core changes in this patch-set? I realize we couldn't easily support sparse id numbers, but not sure this is relevant to hwspinlocks? do we have a use case that couldn't be supported in this case? I actually started out this series with the base_id property, and dropped it in v3 based on comments looking at it from the request-specific-lock semantics with DT. That said, the drivers still need to manage a 'base_id' needed for registration when they get probed for multiple controllers. Getting the base_id from DT _may_ be useful just for registration purposes, but for requesting a hwlock, a controller phandle and an implementation defined args-specifier should suffice IMHO. How could drivers know what the base_id is if DT doesn't provide it? please note that we can't depend on order of controller probing; the hwlock id numbers cannot depend on implementation details. The exact notion of informing the hwspinlock core about a list of reserved locks is missing at the moment (even in the non-DT case). I am not sure if this got lost during the conversion of the registration from per lock to registering a bank of locks together, or if it is implied by the base_id + num_locks combination. The core today supports requesting only those locks that were actually registered, whether allocating a free one dynamically or giving a specific one. Before DT came along, early board code could have reserved specific hwspinlocks if needed. Now with DT, we should add the list of reserved locks to the controller node, in order to prevent them from being dynamically allocated by others. Thanks, Ohad. -- 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: [PATCHv4 0/7] omap hwspinlock dt support
Hi Ohad, On 03/17/2014 09:23 AM, Ohad Ben-Cohen wrote: Hi Suman, On Sat, Mar 15, 2014 at 1:58 AM, Suman Anna s-a...@ti.com wrote: The series doesn't change the semantics of hwspinlock registration or adds a new OF controller registration function. Implementations would still need to register a controller using a base_id and number of locks. The series rather adds a DT-friendly function _ONLY_ for requesting a specific hwlock, and there are no restrictions on the args specifier being relative id numbers. Though this is what the simple default xlate helper does (most common usage), the added xlate ops and #hwlock-cells should allow individual implementation drivers to adjust any variations, and return a relative lock w.r.t its registered base_id, as this is how a lock gets registered in the first place. I might be missing something, but why can't we have the specifier+base_id be the hwlock id and then we can entirely drop most of the core changes in this patch-set? base_id would be a property (if added) of the hwspinlock controller node, and from DT perspective, we will be using the phandle for the controller anyway. So, using a base_id+specifier seems redundant, as the specifier is already w.r.t a hwspinlock controller node. It is best to leave the base_id out, just use the specifier. This is pretty much the standard practice (GPIOs, DMAs, etc all follow this). Please see the comments from Mark regarding the same on an earlier version. http://marc.info/?l=linux-omapm=138135487703774w=2 I realize we couldn't easily support sparse id numbers, but not sure this is relevant to hwspinlocks? do we have a use case that couldn't be supported in this case? I agree on the sparse id numbers on hwspinlock, I don't see a need for it. I actually started out this series with the base_id property, and dropped it in v3 based on comments looking at it from the request-specific-lock semantics with DT. That said, the drivers still need to manage a 'base_id' needed for registration when they get probed for multiple controllers. Getting the base_id from DT _may_ be useful just for registration purposes, but for requesting a hwlock, a controller phandle and an implementation defined args-specifier should suffice IMHO. How could drivers know what the base_id is if DT doesn't provide it? please note that we can't depend on order of controller probing; the hwlock id numbers cannot depend on implementation details. Yes, I agree this is an issue if we have to have the base_ids fixed per controller. But I don't think it makes any difference from requesting a lock from a client DTS node. I can bring it back if Mark agrees. The exact notion of informing the hwspinlock core about a list of reserved locks is missing at the moment (even in the non-DT case). I am not sure if this got lost during the conversion of the registration from per lock to registering a bank of locks together, or if it is implied by the base_id + num_locks combination. The core today supports requesting only those locks that were actually registered, whether allocating a free one dynamically or giving a specific one. Before DT came along, early board code could have reserved specific hwspinlocks if needed. Now with DT, we should add the list of reserved locks to the controller node, in order to prevent them from being dynamically allocated by others. But that strictly relied on the order of requests without any core changes in the hwspinlock core, right. Also mandates that unique locks were requested for different clients (left to board integration). The early board code also has to pass on the reserved hwspinlock information to the actual client driver somehow (platform data). With DT, the early board code is much simplified. Looking at the same scenario from DT case, it seems kinda redundant to specify a set of reserved locks both in the controller node, as well as the respective client drivers, as there is almost no platform data with DT. The only use case for DT client nodes would be for requesting specific locks. I agree with the problem you described, and I think it will require a different set of changes to the core. regards Suman -- 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: [PATCHv4 0/7] omap hwspinlock dt support
Hi Suman, On Mon, Mar 17, 2014 at 9:10 PM, Suman Anna s-a...@ti.com wrote: base_id would be a property (if added) of the hwspinlock controller node, and from DT perspective, we will be using the phandle for the controller anyway. So, using a base_id+specifier seems redundant, as the specifier is already w.r.t a hwspinlock controller node. It is best to leave the base_id out, just use the specifier. This is pretty much the standard practice (GPIOs, DMAs, etc all follow this). Do you mean hwspin_lock_get_id() will return just the specifier instead of base_id+specifier? This is problematic, because Linux will not be able to communicate this lock id outside to a different core running a different OS: that OS will have no idea what hwlock controller this is relative to. Please see the comments from Mark regarding the same on an earlier version. I think I understand and agree with Mark generally, but in this case, the hwlock id is not an implementation detail. Unlike GPIOs/DMAs, this id number is global and system-wide (Linux is just one component in the system, and must use the same predefined id numbers all other cores use, otherwise it will be impossible to use those hwlocks for multi-core synchronization). Yes, I agree this is an issue if we have to have the base_ids fixed per controller. Do you see any other way this could work if the base_ids were not predefined? Linux and some other core running a different OS must agree on the id numbers of the hardware locks we have in the system. Before DT came along, early board code could have reserved specific hwspinlocks if needed. Now with DT, we should add the list of reserved locks to the controller node, in order to prevent them from being dynamically allocated by others. But that strictly relied on the order of requests without any core changes in the hwspinlock core, right. I don't think so, you could request a specific lock by id number. With DT, the early board code is much simplified. Looking at the same scenario from DT case, it seems kinda redundant to specify a set of reserved locks both in the controller node, as well as the respective client drivers, as there is almost no platform data with DT. The only use case for DT client nodes would be for requesting specific locks. I agree with the problem you described, and I think it will require a different set of changes to the core. Exactly. The platform-specific hwspinlock driver will have to inform the core, upon registration, which of the locks are already reserved. In turn, the core will never provide them to clients that dynamically allocate an hwlock: they will be provided only to clients that ask for them specifically (using phandle+specifier). Thanks, Ohad. -- 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: [PATCHv4 0/7] omap hwspinlock dt support
Hi Ohad, On 03/17/2014 02:47 PM, Ohad Ben-Cohen wrote: Hi Suman, On Mon, Mar 17, 2014 at 9:10 PM, Suman Anna s-a...@ti.com wrote: base_id would be a property (if added) of the hwspinlock controller node, and from DT perspective, we will be using the phandle for the controller anyway. So, using a base_id+specifier seems redundant, as the specifier is already w.r.t a hwspinlock controller node. It is best to leave the base_id out, just use the specifier. This is pretty much the standard practice (GPIOs, DMAs, etc all follow this). Do you mean hwspin_lock_get_id() will return just the specifier instead of base_id+specifier? This is problematic, because Linux will not be able to communicate this lock id outside to a different core running a different OS: that OS will have no idea what hwlock controller this is relative to. The behavior of hwspin_lock_get_id() is unchanged, so you will still get the global lock id back. The hwspin_lock_request_specific() (note: not the OF one) will also still be operating on the global lock id. Please see the comments from Mark regarding the same on an earlier version. I think I understand and agree with Mark generally, but in this case, the hwlock id is not an implementation detail. Unlike GPIOs/DMAs, this id number is global and system-wide (Linux is just one component in the system, and must use the same predefined id numbers all other cores use, otherwise it will be impossible to use those hwlocks for multi-core synchronization). Yes, I agree this is an issue if we have to have the base_ids fixed per controller. Do you see any other way this could work if the base_ids were not predefined? Linux and some other core running a different OS must agree on the id numbers of the hardware locks we have in the system. So far, we have not come across multiple controllers. I see your point, and I think this also depends on the semantics of how you exchange the lock id number. The agreement at the moment is on base_ids across multiple SoC components. If the semantics involve exchanging the controller instance, for example, then we might get away with it. But that probably involves adding additional helpers to retrieve controller instance in addition to lock number, or some other similar functions. I can add back the hwlock-base-id binding to the controller node. Mark, Kumar, Do you have any issues adding back this element for registration purposes? Before DT came along, early board code could have reserved specific hwspinlocks if needed. Now with DT, we should add the list of reserved locks to the controller node, in order to prevent them from being dynamically allocated by others. But that strictly relied on the order of requests without any core changes in the hwspinlock core, right. I don't think so, you could request a specific lock by id number. Sorry, I should have rephrased it better - by order, I meant the inherent order between board early code and other drivers. With DT, we cannot guarantee that right, as specific locks are requested from drivers. With DT, the early board code is much simplified. Looking at the same scenario from DT case, it seems kinda redundant to specify a set of reserved locks both in the controller node, as well as the respective client drivers, as there is almost no platform data with DT. The only use case for DT client nodes would be for requesting specific locks. I agree with the problem you described, and I think it will require a different set of changes to the core. Exactly. The platform-specific hwspinlock driver will have to inform the core, upon registration, which of the locks are already reserved. In turn, the core will never provide them to clients that dynamically allocate an hwlock: they will be provided only to clients that ask for them specifically (using phandle+specifier). Understood. And we may have to assign the client association with a lock as well. These are core changes that were actually not needed in the non-DT case due to the inherent order as stated above. So, are you suggesting that we add one more property to the controller node to mark which are reserved, or rely on constructing this through DT tree parsing? regards Suman -- 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: [PATCHv4 0/7] omap hwspinlock dt support
Hi Suman, Mark, On Mon, Feb 24, 2014 at 8:14 PM, Suman Anna s-a...@ti.com wrote: Mark, Ohad, ... Gentle reminder, can you provide your acks/comments? Sorry for the late jump in. I have a few comments: - Hardware spinlocks must have global and system-wide id numbers; these numbers cannot be maintained internally by the Linux Kernel. Think of an SoC with several asynchronous heterogeneous processors, each of which is running a different OS, and they all need to use a specific hardware spinlock in order to share some resource. For that to happen, every hwlock must have a predefined and deterministic id number which is global in the system. We can't have those id numbers be relative to an hwlock controller, and we can't have two hwlock controllers share the same id numbers. - I suspect the simplest and most straight forward way to achieve this is by (a) bringing back the concept of the base_id property, and (b) letting the global hwlock id be the DT identifier (plus the base_id) and then providing it directly to the drivers when needed. The latter is required in order to support dynamically allocation of hwlocks, in which case Linux must know the global system-wide id number, and then share it with the other asynchronous OSes via some IPC. - If we feel there's no way any system is going to have more than a single hwlock controller, then we can live without a base_id property, but then this needs to be clearly documented and prohibited. Today both the hwlock DT representation, and the coupled kernel code, implicitly allow this anomaly to exist. - Hwlock controller nodes should have a list of reserved locks (those locks for which other nodes have a phandle+identifier pointing at) to prevent those locks from being dynamically allocated by eager drivers. Most of these issues were discussed Arnd, Benoit and myself back then, please see below: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/064265.html Let's discuss, Thanks, Ohad. -- 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: [PATCHv4 0/7] omap hwspinlock dt support
Hi Ohad, On 03/14/2014 03:10 PM, Ohad Ben-Cohen wrote: Hi Suman, Mark, On Mon, Feb 24, 2014 at 8:14 PM, Suman Anna s-a...@ti.com wrote: Mark, Ohad, ... Gentle reminder, can you provide your acks/comments? Sorry for the late jump in. I have a few comments: Thanks for the comments. It probably covers few topics that are slightly beyond the scope of the series, but nevertheless are good discussion points for finalizing the series. - Hardware spinlocks must have global and system-wide id numbers; these numbers cannot be maintained internally by the Linux Kernel. Think of an SoC with several asynchronous heterogeneous processors, each of which is running a different OS, and they all need to use a specific hardware spinlock in order to share some resource. For that to happen, every hwlock must have a predefined and deterministic id number which is global in the system. We can't have those id numbers be relative to an hwlock controller, and we can't have two hwlock controllers share the same id numbers. The series doesn't change the semantics of hwspinlock registration or adds a new OF controller registration function. Implementations would still need to register a controller using a base_id and number of locks. The series rather adds a DT-friendly function _ONLY_ for requesting a specific hwlock, and there are no restrictions on the args specifier being relative id numbers. Though this is what the simple default xlate helper does (most common usage), the added xlate ops and #hwlock-cells should allow individual implementation drivers to adjust any variations, and return a relative lock w.r.t its registered base_id, as this is how a lock gets registered in the first place. - I suspect the simplest and most straight forward way to achieve this is by (a) bringing back the concept of the base_id property, and I actually started out this series with the base_id property, and dropped it in v3 based on comments looking at it from the request-specific-lock semantics with DT. That said, the drivers still need to manage a 'base_id' needed for registration when they get probed for multiple controllers. Getting the base_id from DT _may_ be useful just for registration purposes, but for requesting a hwlock, a controller phandle and an implementation defined args-specifier should suffice IMHO. (b) letting the global hwlock id be the DT identifier (plus the base_id) and then providing it directly to the drivers when needed.The latter is required in order to support dynamically allocation of hwlocks, in which case Linux must know the global system-wide id number, and then share it with the other asynchronous OSes via some IPC. Each lock still retains a global lock id value, and you can retrieve it using the existing hwspin_lock_get_id(). Why is the latter required for dynamic allocation, isn't it the other way around, allocate a lock, and you will be able to get the lock id. If wanting to request a specific lock received across, the regular hwspin_lock_request_specific should be used. - If we feel there's no way any system is going to have more than a single hwlock controller, then we can live without a base_id property, but then this needs to be clearly documented and prohibited. Today both the hwlock DT representation, and the coupled kernel code, implicitly allow this anomaly to exist. I haven't removed the concept of base_id, it is just not defined in the DT-bindings, and am currently expecting the drivers to manage it and use it for registration. - Hwlock controller nodes should have a list of reserved locks (those locks for which other nodes have a phandle+identifier pointing at) to prevent those locks from being dynamically allocated by eager drivers. The exact notion of informing the hwspinlock core about a list of reserved locks is missing at the moment (even in the non-DT case). I am not sure if this got lost during the conversion of the registration from per lock to registering a bank of locks together, or if it is implied by the base_id + num_locks combination. The core today supports requesting only those locks that were actually registered, whether allocating a free one dynamically or giving a specific one. There were some slightly similar comments from Kumar earlier on the v2 series, please see the thread in [1]. Most of these issues were discussed Arnd, Benoit and myself back then, please see below: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/064265.html Thanks for the pointer to the previous discussion, I wasn't aware of an earlier attempt. The primary approach on requesting locks is actually no different from what Arnd suggested originally. regards Suman [1] http://marc.info/?l=linux-omapm=138031002012191w=2 -- 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: [PATCHv4 0/7] omap hwspinlock dt support
Mark, Ohad, On 02/10/2014 01:27 PM, Suman Anna wrote: Mark, On 01/13/2014 06:19 PM, Suman Anna wrote: Hi, This is an updated series mainly addressing Mark Rutland's comments about hwlock specifier being always one-cell. The series adds the support for #hwlock-cells property and adds a simple default OF translate function. The DTS patches from previous series have already been merged, and needs this property to be added. This is handled in a separate series that only deals with OMAP hwspinlock DTS patches. The series, along with the DTS patches, is tested on top of v3.13-rc8 plus Tero's v13 clock DT series and Tony's 3.14 staged branches. The validation on OMAP5, DRA7, AM437 requires Tero's series with couple of additional base patches for AM43xx. AM43xx functionality needs a hwmod fix [1] for creating the associated omap_device as well. Can you please take a look at this series and give your ack on the bindings if you do not have any further comments? The only comments so far are from Bjorn on the OF helpers. Gentle reminder, can you provide your acks/comments? regards Suman -- 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: [PATCHv4 0/7] omap hwspinlock dt support
Mark, On 01/13/2014 06:19 PM, Suman Anna wrote: Hi, This is an updated series mainly addressing Mark Rutland's comments about hwlock specifier being always one-cell. The series adds the support for #hwlock-cells property and adds a simple default OF translate function. The DTS patches from previous series have already been merged, and needs this property to be added. This is handled in a separate series that only deals with OMAP hwspinlock DTS patches. The series, along with the DTS patches, is tested on top of v3.13-rc8 plus Tero's v13 clock DT series and Tony's 3.14 staged branches. The validation on OMAP5, DRA7, AM437 requires Tero's series with couple of additional base patches for AM43xx. AM43xx functionality needs a hwmod fix [1] for creating the associated omap_device as well. Can you please take a look at this series and give your ack on the bindings if you do not have any further comments? The only comments so far are from Bjorn on the OF helpers. regards Suman -- 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: [PATCHv4 0/7] omap hwspinlock dt support
On Mon, Jan 13, 2014 at 06:19:17PM -0600, Suman Anna wrote: This is an updated series mainly addressing Mark Rutland's comments about hwlock specifier being always one-cell. The series adds the support for #hwlock-cells property and adds a simple default OF translate function. The DTS patches from previous series have already been merged, and needs this property to be added. This is handled in a separate series that only deals with OMAP hwspinlock DTS patches. The series, along with the DTS patches, is tested on top of v3.13-rc8 plus Tero's v13 clock DT series and Tony's 3.14 staged branches. The validation on OMAP5, DRA7, AM437 requires Tero's series with couple of additional base patches for AM43xx. AM43xx functionality needs a hwmod fix [1] for creating the associated omap_device as well. The validation logs on all the applicable OMAP SoCs are at: OMAP4 - http://paste2.org/YJ7ZwG80 OMAP5 - http://paste2.org/c6vO96b9 DRA7 - http://paste2.org/tHvxN439 AM33x - http://paste2.org/AjCv0U4t AM43x - http://paste2.org/2AKIPa55 I build tested your 3.13-rc8-v4 branch with the same script I used to build CCF series and hspinlock built without any problems ;-) Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
[PATCHv4 0/7] omap hwspinlock dt support
Hi, This is an updated series mainly addressing Mark Rutland's comments about hwlock specifier being always one-cell. The series adds the support for #hwlock-cells property and adds a simple default OF translate function. The DTS patches from previous series have already been merged, and needs this property to be added. This is handled in a separate series that only deals with OMAP hwspinlock DTS patches. The series, along with the DTS patches, is tested on top of v3.13-rc8 plus Tero's v13 clock DT series and Tony's 3.14 staged branches. The validation on OMAP5, DRA7, AM437 requires Tero's series with couple of additional base patches for AM43xx. AM43xx functionality needs a hwmod fix [1] for creating the associated omap_device as well. The validation logs on all the applicable OMAP SoCs are at: OMAP4 - http://paste2.org/YJ7ZwG80 OMAP5 - http://paste2.org/c6vO96b9 DRA7 - http://paste2.org/tHvxN439 AM33x - http://paste2.org/AjCv0U4t AM43x - http://paste2.org/2AKIPa55 The kernel with the test patches plus the various pulled in branches is here for reference (not for merging) https://github.com/sumananna/omap-kernel/commits/hwspinlock/3.13-rc8-v4-test [1] http://marc.info/?l=linux-omapm=138939747524820w=2 Changes new in v4: - The DT bindings are split into separate patches, and updated to add comments about #hwlock-cells (Patches 1 2) - Fixed a registration issue with repeated module installation and removal. (Patch 3) - Added a new OF helper to support #hwlock-cells in addition to the previous OF functions (Patch 4). The OMAP adaptation patch is updated to use the default translate function (Patch 5) - Updated hwspinlock documentation to adjust for the structure changes and the new api additions. (Patches 3, 4) - Added build support for AM335x, AM43xx and DRA7xx (Patch 7) - The AM335/AM43x fix patch is unchanged (Patch 6) v3: - Removed the DT property hwlock-base-id and associated OF helper - Added changes in core to support requesting a specific hwlock using phandle + args approach - Revised both the common and OMAP DT bindings document http://marc.info/?l=linux-omapm=138143992932197w=2 v2: - Added a new common DT binding documentation and OF helpers. - Revised OMAP DT parse support to use the new OF helper (Patch2) - OMAP5 hwspinlock support including the hwmod entry and DT node - Add AM335x support to OMAP hwspinlock driver, including a fix needed in driver given that AM335 spinlock module requires s/w wakeup - AM335 DT node for spinlock, and a hwmod change to enable smart-idle for AM335. - OMAP4 DT node patch is unchanged http://marc.info/?l=linux-omapm=137944644112727w=2 v1: - Add DT parse support to OMAP hwspinlock driver - Add OMAP4 DT node and bindings information http://marc.info/?l=linux-omapm=137823082308009w=2 Suman Anna (7): Documentation: dt: add common bindings for hwspinlock Documentation: dt: add the omap hwspinlock bindings document hwspinlock/core: maintain a list of registered hwspinlock banks hwspinlock/core: add common OF helpers hwspinlock/omap: add support for dt nodes hwspinlock/omap: enable module before reading SYSSTATUS register hwspinlock/omap: enable build for AM33xx, AM43xx DRA7xx .../devicetree/bindings/hwlock/hwlock.txt | 52 +++ .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 24 Documentation/hwspinlock.txt | 36 - MAINTAINERS| 1 - arch/arm/mach-omap2/Makefile | 3 - arch/arm/mach-omap2/hwspinlock.c | 60 drivers/hwspinlock/Kconfig | 2 +- drivers/hwspinlock/hwspinlock_core.c | 159 - drivers/hwspinlock/hwspinlock_internal.h | 6 + drivers/hwspinlock/omap_hwspinlock.c | 39 +++-- include/linux/hwspinlock.h | 20 ++- 11 files changed, 321 insertions(+), 81 deletions(-) create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt delete mode 100644 arch/arm/mach-omap2/hwspinlock.c -- 1.8.4.3 -- 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
