- 24 Jun, 2013 1 commit
-
-
Fabio Baltieri authored
Fix sparse warnings: drivers/dma/ste_dma40.c:81:26: warning: symbol 'dma40_memcpy_conf_phy' was not declared. Should it be static? drivers/dma/ste_dma40.c:95:26: warning: symbol 'dma40_memcpy_conf_log' was not declared. Should it be static? Signed-off-by:
Fabio Baltieri <fabio.baltieri@linaro.org> Acked-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
- 04 Jun, 2013 20 commits
-
-
Wei Yongjun authored
In many of the error handling case, the return value 'ret' not set and 0 will be return from d40_probe() even if error, but we should return a negative error code instead in those error handling case. This patch fixed them, and also removed useless variable 'err'. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
-
Lee Jones authored
Some platforms have channels which are not available for normal use. This information is currently passed though platform data in internal BSP kernels. Once those platforms land, they'll need to configure them appropriately, so we may as well add the infrastructure. Cc: Dan Williams <djbw@fb.com> Cc: Per Forlin <per.forlin@stericsson.com> Cc: Rabin Vincent <rabin@rab.in> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Lee Jones authored
Some platforms insist on obscure physical channel availability. This information is currently passed though platform data in internal BSP kernels. Once those platforms land, they'll need to configure them appropriately, so we may as well add the infrastructure. Cc: Dan Williams <djbw@fb.com> Cc: Per Forlin <per.forlin@stericsson.com> Cc: Rabin Vincent <rabin@rab.in> Acked-by:
-
Lee Jones authored
The DMA platform data is now empty due to some recent refactoring, so there is no longer a requirement to pass it though. Acked-by:
-
Lee Jones authored
At this moment in time the memcpy channels which can be used by the D40 are fixed, as each supported platform in Mainline uses the same ones. However, platforms do exist which don't follow this convention, so these will need to be tailored. Fortunately, these platforms will be DT only, so this change has very little impact on platform data. Cc: Dan Williams <djbw@fb.com> Cc: Per Forlin <per.forlin@stericsson.com> Cc: Rabin Vincent <rabin@rab.in> Acked-by:
-
Lee Jones authored
Unsure of the author's intentions, rather than just removing the nop, we're replacing it with a comment containing the possible intention of the statement OR:ing with 0. Cc: Dan Williams <djbw@fb.com> Cc: Per Forlin <per.forlin@stericsson.com> Cc: Rabin Vincent <rabin@rab.in> Acked-by:
-
Lee Jones authored
When a DMA client requests and configures a DMA channel, it requests data_width in Bytes. The DMA40 driver then swiftly converts it over to the necessary register bit value. Unfortunately, for any subsequent calculations we have to shift '1' by the bit pattern (1 << data_width) times to make any sense of it. This patch flips the semantics on its head and only converts the value to its respective register bit pattern when writing to registers. This way we can use the true data_width (in Bytes) value. Cc: Dan Williams <djbw@fb.com> Cc: Per Forlin <per.forlin@stericsson.com> Cc: Rabin Vincent <rabin@rab.in> Acked-by:
-
Lee Jones authored
The aim is to make the code that little more readable. Cc: Dan Williams <djbw@fb.com> Cc: Per Forlin <per.forlin@stericsson.com> Cc: Rabin Vincent <rabin@rab.in> Acked-by:
-
Lee Jones authored
We're now using the transfer direction definitions provided by the DMA sub-system, so the home-brew ones have become obsolete. Signed-off-by:
-
Lee Jones authored
STEDMA40_*_TO_* direction definitions are identical in all but name to the pre-defined generic DMA_*_TO_* ones. Let's make things easy by not duplicating such things. Cc: Dan Williams <djbw@fb.com> Cc: Per Forlin <per.forlin@stericsson.com> Cc: Rabin Vincent <rabin@rab.in> Acked-by:
-
Lee Jones authored
STEDMA40_*_TO_* direction definitions are identical in all but name to the pre-defined generic DMA_*_TO_* ones. Let's make things easy by not duplicating such things. Signed-off-by:
-
Lee Jones authored
The aim is to make the code that little more readable. Acked-by:
Vinod Koul <vnod.koul@intel.com> Acked-by:
-
Lee Jones authored
As promised, now all devices which resided in u8500_of_init_devices() have been enabled for Device Tree, we can completely remove it. Acked-by:
-
Lee Jones authored
Now the ux500-musb driver has been enabled for Device Tree, there is no requirement to register it from platform code. Acked-by:
-
Lee Jones authored
This patch will allow ux500-musb to be probed and configured solely from configuration found in Device Tree. Cc: Rob Herring <rob.herring@calxeda.com> Cc: linux-usb@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org Acked-by:
Felipe Balbi <balbi@ti.com> Acked-by:
-
Lee Jones authored
If we can ever get to a state where we can solely search for DMA channels by name, this will almost completely alleviate the requirement to pass copious amounts of information though platform data. Here we take the first step towards this. The next step will be to enable Device Tree complete with name<->event_line mapping. Cc: linux-usb@vger.kernel.org Acked-by:
-
Lee Jones authored
In its current state, the ux500-musb driver uses platform data pointers blindly with no prior checking. If no platform data pointer is passed this will Oops the kernel. In this patch we ensure platform data and board data are present prior to using them. Cc: linux-usb@vger.kernel.org Acked-by:
-
Lee Jones authored
The dma_mask will always be the same as the coherent_dma_mask, so let's cut down on the platform_data burden and set it as such in the driver. This also saves us from supporting it separately when we come to enable this driver for Device Tree. Cc: linux-usb@vger.kernel.org Acked-by:
-
Lee Jones authored
The MUSB HDRC configuration never changes between each of the ux500 supported platforms, so there's little point passing it though platform data. If we set it in the driver instead, we can make good use of it when booting with either ATAGs or Device Tree. Cc: linux-usb@vger.kernel.org Acked-by:
-
Lee Jones authored
For all ux500 based platforms the maximum number of end-points are used. Move this knowledge into the driver so we can relinquish the burden from platform data. This also removes quite a bit of complexity from the driver and will aid us when we come to enable the driver for Device Tree. Cc: linux-usb@vger.kernel.org Acked-by:
-
- 23 May, 2013 19 commits
-
-
Lee Jones authored
These drivers are now operational and even use the latest common clk and DMA APIs. There's no reason why we shouldn't start them up now. Signed-off-by:
-
Lee Jones authored
The Cryp driver is currently silent and the Hash driver prints the name of its probe function unnecessarily. Let's just put a nice descriptive one-liner there instead. Cc: David S. Miller <davem@davemloft.net> Cc: Andreas Westin <andreas.westin@stericsson.com> Cc: linux-crypto@vger.kernel.org Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Acked-by:
-
Lee Jones authored
DMA channel configuration information should be setup in the driver. The Ux500 Cryp driver now does this, so there's no need to send it though here too. Acked-by:
-
Lee Jones authored
The DMA controller currently takes configuration information from information passed though dma_channel_request(), but it shouldn't. Using the API, the DMA channel should only be configured during a dma_slave_config() call. Cc: David S. Miller <davem@davemloft.net> Cc: Andreas Westin <andreas.westin@stericsson.com> Cc: linux-crypto@vger.kernel.org Acked-by:
-
Lee Jones authored
If we fail to prepare the ux500-cryp clock before enabling it the platform will fail to boot. Here we insure this happens. Cc: David S. Miller <davem@davemloft.net> Cc: Andreas Westin <andreas.westin@stericsson.com> Cc: linux-crypto@vger.kernel.org Acked-by:
Ulf Hansson <ulf.hansson@linaro.org> Acked-by:
-
Lee Jones authored
DMA channel configuration information should be setup in the driver. The Ux500 Hash driver now does this, so there's no need to send it though here too. Acked-by:
-
Lee Jones authored
The DMA controller currently takes configuration information from information passed though dma_channel_request(), but it shouldn't. Using the API, the DMA channel should only be configured during a dma_slave_config() call. Cc: David S. Miller <davem@davemloft.net> Cc: Andreas Westin <andreas.westin@stericsson.com> Cc: linux-crypto@vger.kernel.org Acked-by:
-
Lee Jones authored
If we fail to prepare the ux500-hash clock before enabling it the platform will fail to boot. Here we insure this happens. Cc: David S. Miller <davem@davemloft.net> Cc: Andreas Westin <andreas.westin@stericsson.com> Cc: linux-crypto@vger.kernel.org Acked-by:
-
Lee Jones authored
DMA data width and packet size information is only required at channel configuration time. Any information passed from platform data is passed directly to the DMA40 driver to use during channel allocation, but these pieces of information are subsequently ignored by the driver, so we may as well remove them. Signed-off-by:
-
Lee Jones authored
'struct stedma40_half_channel_info's header comment says that it's called 'struct stedma40_chan_cfg'. Let's straighten that out. Signed-off-by:
-
Lee Jones authored
DMA addresses are now passed as part of the dmaengine API by invoking dmaengine_slave_config(). So there's no requirement for the DMA40 driver to look them up in a table provided by platform data. This method does not fit in well using Device Tree either. Acked-by:
-
Lee Jones authored
Addresses are now stored in local data structures and are easy to obtain, thus a specialist function used to fetch them is now surplus to requirement. Signed-off-by:
-
Lee Jones authored
Addresses are passed in from the client's driver via the invocation of dmaengine_slave_config(), so there's no need to fetch them from platform data too, hardwired or otherwise. This is a great step forward, as it elevates a large burden from platform data in the way of a look-up table. Signed-off-by:
-
Lee Jones authored
It was required to pass DMA channel configuration information to the UART driver before the new DMA API was in place. Now that it is, and is fully compatible with Device Tree we can stop doing that. Reviewed-by:
-
Lee Jones authored
Using the dmaengine API for slave transfers, allocating and configuring a channel are two separate actions. Here we're removing logical channel configuration from the channel allocation routine for slave transfers, as the same config is already done in the runtime config function, and put the corresponding call into d40_config_memcpy() for the memcpy code path. Cc: Dan Williams <djbw@fb.com> Cc: Per Forlin <per.forlin@stericsson.com> Cc: Rabin Vincent <rabin@rab.in> Acked-by:
-
Lee Jones authored
The majority of configuration done in d40_phy_config() pertains to physical channels. Move the call over to runtime config which has different code paths for physical and logical channels already, and make it an exclusive physical channel config function as the name implies, and drop the is_log argument. Since we moved the call to runtime_config() it only gets called for device transfers, so encode the small snippet of configuration pertaining to memcpy channels into the d40_config_memcpy() function. Acked-by:
-
Lee Jones authored
During the initial setup of a logical channel, it is necessary to unmask the GIM in order to receive generated terminal count and error interrupts. We're separating out this required code so it will be possible to move the remaining code in d40_phy_cfg(), which is mostly runtime configuration into the runtime_config() routine. Cc: Dan Williams <djbw@fb.com> Cc: Per Forlin <per.forlin@stericsson.com> Cc: Rabin Vincent <rabin@rab.in> Acked-by:
-
Lee Jones authored
Ironically, in order to remove lots of the auxdata assignments, we have to add just one more. A lot of them require DMA information to be passed into clients for DMA channel allocation, but we now have this capability in Device Tree. However, the DMA40 driver still relies on a reverse table look-up to obtain DMA addresses. Until all of the clients are converted, over to the new API, we're stuck with this. Also, now the DMA40 has been DT:ed, there's no requirement to register it using traditional methods, so let's remove it. Acked-by:
-
Lee Jones authored
Using the new DMA DT bindings and API, we can register the DMA40 driver as Device Tree capable. Now, when a client attempts to allocate a channel using the DMA DT bindings via its own node, we are able to parse the request and allocate a channel in the correct manner. Cc: Dan Williams <djbw@fb.com> Cc: Per Forlin <per.forlin@stericsson.com> Cc: Rabin Vincent <rabin@rab.in> Cc: Rob Herring <rob.herring@calxeda.com> Cc: devicetree-discuss@lists.ozlabs.org Acked-by:
-
