1. 30 4月, 2014 1 次提交
    • R
      of/fdt: Convert FDT functions to use libfdt · e6a6928c
      Rob Herring 提交于
      The kernel FDT functions predate libfdt and are much more limited in
      functionality. Also, the kernel functions and libfdt functions are
      not compatible with each other because they have different definitions
      of node offsets. To avoid this incompatibility and in preparation to
      add more FDT parsing functions which will need libfdt, let's first
      convert the existing code to use libfdt.
      
      The FDT unflattening, top-level FDT scanning, and property retrieval
      functions are converted to use libfdt. The scanning code should be
      re-worked to be more efficient and understandable by using libfdt to
      find nodes directly by path or compatible strings.
      Signed-off-by: NRob Herring <robh@kernel.org>
      Tested-by: NMichal Simek <michal.simek@xilinx.com>
      Tested-by: NGrant Likely <grant.likely@linaro.org>
      Tested-by: NStephen Chivers <schivers@csc.com>
      e6a6928c
  2. 12 3月, 2014 1 次提交
  3. 15 10月, 2013 1 次提交
  4. 27 8月, 2013 1 次提交
  5. 23 8月, 2013 1 次提交
    • W
      i2c: move OF helpers into the core · 687b81d0
      Wolfram Sang 提交于
      I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
      that it is much cleaner to have this in the core. This also removes a
      circular dependency between the helpers and the core, and so we can
      finally register child nodes in the core instead of doing this manually
      in each driver. So, fix the drivers and documentation, too.
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      687b81d0
  6. 12 6月, 2013 1 次提交
  7. 14 2月, 2013 1 次提交
  8. 07 1月, 2013 1 次提交
    • J
      of: Add generic device tree DMA helpers · aa3da644
      Jon Hunter 提交于
      This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
      to add some basic helpers to retrieve a DMA controller device_node and the
      DMA request/channel information.
      
      Aim of DMA helpers
      - The purpose of device-tree is to describe the capabilites of the hardware.
        Thinking about DMA controllers purely from the context of the hardware to
        begin with, we can describe a device in terms of a DMA controller as
        follows ...
        	1. Number of DMA controllers
      	2. Number of channels (maybe physical or logical)
      	3. Mapping of DMA requests signals to DMA controller
      	4. Number of DMA interrupts
      	5. Mapping of DMA interrupts to channels
      - With the above in mind the aim of the DT DMA helper functions is to extract
        the above information from the DT and provide to the appropriate driver.
        However, due to the vast number of DMA controllers and not all are using a
        common driver (such as DMA Engine) it has been seen that this is not a
        trivial task. In previous discussions on this topic the following concerns
        have been raised ...
      	1. How does the binding support devices with multiple DMA controllers?
        	2. How to support both legacy DMA controllers not using DMA Engine as
      	   well as those that support DMA Engine.
      	3. When using with DMA Engine how do we support the various
      	   implementations where the opaque filter function parameter differs
      	   between implementations?
      	4. How do we handle DMA channels that are identified with a string
      	   versus a integer?
      - Hence the design of the DMA helpers has to accomodate the above or align on
        an agreement what can be or should be supported.
      
      Design of DMA helpers
      
      1. Registering DMA controllers
      
         In the case of DMA controllers that are using DMA Engine, requesting a
         channel is performed by calling the following function.
      
      	struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
      			dma_filter_fn filter_fn,
      			void *filter_param);
      
         The mask variable is used to match a type of the device controller in a list
         of controllers. The filter_fn and filter_param are used to identify the
         required dma channel and return a handle to the dma channel of type dma_chan.
      
         From the examples I have seen, the mask and filter_fn are constant
         for a given DMA controller and therefore, we can specify these as controller
         specific data when registering the DMA controller with the device-tree DMA
         helpers.
      
         The filter_param variable is of an unknown type and is typically specific
         to the DMA engine implementation for a given DMA controller. To allow some
         flexibility in the type and formating of this filter_param we employ an
         xlate to translate the device-tree binding information into the appropriate
         format. The xlate function used for a DMA controller can also be specified
         when registering the DMA controller with the device-tree DMA helpers.
      
         Based upon the above, a function for registering the DMA controller with the
         DMA helpers now looks like the below. The data variable is used to pass a
         pointer to DMA controller specific data used by the xlate function.
      
      	int of_dma_controller_register(struct device_node *np,
      		struct dma_chan *(*of_dma_xlate)
      		(struct of_phandle_args *, struct of_dma *),
      		void *data)
      
         For example, in the case where DMA engine is used, we define the following
         structure (that stores the DMA engine capability mask and filter function)
         and pass this to the data variable in the above function.
      
      	struct of_dma_filter_info {
      		dma_cap_mask_t  dma_cap;
      		dma_filter_fn   filter_fn;
      	};
      
      2. Representing and requesting channel information
      
         Please see the dma binding documentation included in this patch for a
         description of how DMA controllers and client information should be
         represented with device-tree. For more information on how this binding
         came about please see [3]. In addition to this, feedback received from
         the Linux kernel summit showed a consensus (among those who attended) to
         use a name to identify DMA client information [4].
      
         A DMA channel can be requested by calling the following function, where name
         is a required parameter used for identifying a DMA channel. This function
         has been designed to return a structure of type dma_chan to work with the
         DMA engine driver. Note that if DMA engine is used then drivers should be
         using the DMA engine API dma_request_slave_channel() (implemented in part 2
         of this series, "dmaengine: add helper function to request a slave DMA
         channel") which will in turn call the below function if device-tree is
         present. The aim being to have a common DMA engine interface regardless of
         whether device tree is being used.
      
      	struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
      						      char *name)
      
      3. Supporting legacy devices not using DMA Engine
      
         These devices present a problem, as there may not be a uniform way to easily
         support them with regard to device tree. Ideally, these should be migrated
         to DMA engine. However, if this is not possible, then they should still be
         able to use this binding, the only constaint imposed by this implementation
         is that when requesting a DMA channel via of_dma_request_slave_channel(), it
         will return a type of dma_chan.
      
      This implementation has been tested on OMAP4430 using the kernel v3.6-rc5. I
      have validated that MMC is working on the PANDA board with this implementation.
      My development branch for testing on OMAP can be found here [5].
      
      v6: - minor corrections in DMA binding documentation
      v5: - minor update to binding documentation
          - added loop to exhaustively search for a slave channel in the case where
            there could be alternative channels available
      v4: - revert the removal of xlate function from v3
          - update the proposed binding format and APIs based upon discussions [3]
      v3: - avoid passing an xlate function and instead pass DMA engine parameters
          - define number of dma channels and requests in dma-controller node
      v2: - remove of_dma_to_resource API
          - make property #dma-cells required (no fallback anymore)
          - another check in of_dma_xlate_onenumbercell() function
      
      [1] http://article.gmane.org/gmane.linux.drivers.devicetree/12022
      [2] http://article.gmane.org/gmane.linux.ports.arm.omap/73622
      [3] http://marc.info/?l=linux-omap&m=133582085008539&w=2
      [4] http://pad.linaro.org/arm-mini-summit-2012
      [5] https://github.com/jonhunter/linux/tree/dev-dt-dma
      
      Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Stephen Warren <swarren@nvidia.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Vinod Koul <vinod.koul@intel.com>
      Cc: Dan Williams <djbw@fb.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Reviewed-by: NStephen Warren <swarren@wwwdotorg.org>
      Acked-by: NRob Herring <rob.herring@calxeda.com>
      Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
      aa3da644
  9. 14 4月, 2012 1 次提交
  10. 08 4月, 2012 1 次提交
  11. 15 3月, 2012 1 次提交
  12. 13 12月, 2011 1 次提交
  13. 08 6月, 2011 1 次提交
    • B
      pci/of: Match PCI devices to OF nodes dynamically · 98d9f30c
      Benjamin Herrenschmidt 提交于
      powerpc has two different ways of matching PCI devices to their
      corresponding OF node (if any) for historical reasons. The ppc64 one
      does a scan looking for matching bus/dev/fn, while the ppc32 one does a
      scan looking only for matching dev/fn on each level in order to be
      agnostic to busses being renumbered (which Linux does on some
      platforms).
      
      This removes both and instead moves the matching code to the PCI core
      itself. It's the most logical place to do it: when a pci_dev is created,
      we know the parent and thus can do a single level scan for the matching
      device_node (if any).
      
      The benefit is that all archs now get the matching for free. There's one
      hook the arch might want to provide to match a PHB bus to its device
      node. A default weak implementation is provided that looks for the
      parent device device node, but it's not entirely reliable on powerpc for
      various reasons so powerpc provides its own.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NMichal Simek <monstr@monstr.eu>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      98d9f30c
  14. 05 2月, 2011 1 次提交
  15. 01 11月, 2010 1 次提交
  16. 11 10月, 2010 1 次提交
  17. 06 7月, 2010 1 次提交
  18. 29 6月, 2010 1 次提交
  19. 24 11月, 2009 1 次提交
  20. 27 4月, 2009 1 次提交
  21. 26 7月, 2008 1 次提交
  22. 20 4月, 2008 1 次提交
  23. 17 4月, 2008 2 次提交
  24. 20 7月, 2007 3 次提交