An error occurred fetching the project authors.
  1. 07 Jan, 2010 1 commit
  2. 30 Oct, 2009 1 commit
  3. 15 Oct, 2009 1 commit
    • Eilon Greenstein's avatar
      bnx2x: Allowing 0 as initial fairness value · b015e3d1
      Eilon Greenstein authored
      Value of zero was used to disable the fairness mechanism. Though the code
      (driver and FW) allowed changing the value at run time, it did not allow to do
      that if the mechanism was disabled to begin with.
      Fixed the FW to allow turning on and off the mechanism at run time. Fixed the
      code to read the value from the chip at the right sequence.
      Without this fix, if the initial value was set to zero, traffic could not run on
      the interface.
      Signed-off-by: default avatarEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b015e3d1
  4. 05 Oct, 2009 1 commit
  5. 15 Sep, 2009 1 commit
  6. 30 Aug, 2009 1 commit
    • Ben Hutchings's avatar
      radeon: Use request_firmware() · 70967ab9
      Ben Hutchings authored
      Loosely based on a patch by
      Jaswinder Singh Rajput <jaswinderlinux@gmail.com>.
      
      KMS support by Dave Airlie <airlied@redhat.com>.
      
      For Radeon 100- to 500-series, firmware blobs look like:
          struct {
              __be32 datah;
              __be32 datal;
          } cp_ucode[256];
      
      For Radeon 600-series, there are two separate firmware blobs:
          __be32 me_ucode[PM4_UCODE_SIZE * 3];
          __be32 pfp_ucode[PFP_UCODE_SIZE];
      
      For Radeon 700-series, likewise:
          __be32 me_ucode[R700_PM4_UCODE_SIZE];
          __be32 pfp_ucode[R700_PFP_UCODE_SIZE];
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      70967ab9
  7. 29 Aug, 2009 1 commit
  8. 27 Aug, 2009 2 commits
  9. 13 Aug, 2009 1 commit
    • Eilon Greenstein's avatar
      bnx2x: Using the new FW · ca00392c
      Eilon Greenstein authored
      The new FW improves the packets per second rate. It required a lot of change in
      the FW which implies many changes in the driver to support it. It is now also
      possible for the driver to use a separate MSI-X vector for Rx and Tx - this also
      add some to the complicity of this change.
      
      All things said - after this patch, practically all performance matrixes show
      improvement.
      Though Vladislav Zolotarov is not signed on this patch, he did most of the job
      and deserves credit for that.
      Signed-off-by: default avatarEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ca00392c
  10. 08 Jul, 2009 1 commit
  11. 04 Jun, 2009 1 commit
  12. 02 May, 2009 1 commit
  13. 27 Apr, 2009 1 commit
    • Vladislav Zolotarov's avatar
      bnx2x: Separated FW from the source. · 94a78b79
      Vladislav Zolotarov authored
      >From now on FW will be downloaded from the binary file using request_firmware.
      
      There will be different files for every supported chip. Currently 57710 (e1) and
      57711 (e1h).
      
      File names have the following format: bnx2x-<chip version>-<FW version>.fw.
      ihex versions of current FW files are submitted in the next patch.
      
      Each binary file has a header in the following format:
      
      
      struct bnx2x_fw_file_section {
      	__be32 len;
      	__be32 offset;
      }
      
      struct bnx2x_fw_file_hdr {
      	struct bnx2x_fw_file_section init_ops;
      	struct bnx2x_fw_file_section init_ops_offsets;
      	struct bnx2x_fw_file_section init_data;
      	struct bnx2x_fw_file_section tsem_int_table_data;
      	struct bnx2x_fw_file_section tsem_pram_data;
      	struct bnx2x_fw_file_section usem_int_table_data;
      	struct bnx2x_fw_file_section usem_pram_data;
      	struct bnx2x_fw_file_section csem_int_table_data;
      	struct bnx2x_fw_file_section csem_pram_data;
      	struct bnx2x_fw_file_section xsem_int_table_data;
      	struct bnx2x_fw_file_section xsem_pram_data;
      	struct bnx2x_fw_file_section fw_version;
      }
      
      Each bnx2x_fw_file_section contains the length and the offset of the appropriate
      section in the binary file. Values are stored in the big endian format.
      
      Data types of arrays:
      
      init_data            __be32
      init_ops_offsets     __be16
      XXsem_pram_data         u8
      XXsem_int_table_data    u8
      init_ops             struct raw_op {
                                u8   op;
      			__be24 offset;
                              __be32 data;
      		     }
      fw_version              u8
      
      >From now boundaries of a specific initialization stage are stored in
      init_ops_offsets array instead of being defined by separate macroes. The index 
      in init_ops_offsets is calculated by BLOCK_OPS_IDX macro:
      
      #define BLOCK_OPS_IDX(block, stage, end) \
             (2*(((block)*STAGE_IDX_MAX) + (stage)) + (end))
      
      Security:
      
      In addition to sanity check of array boundaries bnx2x will check a FW version.
      Additional checks might be added in the future.
      Signed-off-by: default avatarVladislav Zolotarov <vladz@broadcom.com>
      Signed-off-by: default avatarEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      94a78b79
  14. 21 Apr, 2009 1 commit
  15. 07 Apr, 2009 1 commit
    • David Woodhouse's avatar
      firmware: Remove newly-added slicoss and sxg firmware images · cec20f36
      David Woodhouse authored
      These are available elsewhere (for example in the linux-firmware.git
      repository); they have no business being added to the kernel source
      tree.
      
      We are only putting stuff in the firmware/ directory of the kernel
      source when it's extracted from long-standing drivers which used to
      include it directly.
      
      We didn't intend to open the floodgates to including megabytes of new
      firmware which was previously being distributed separately.
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      cec20f36
  16. 06 Apr, 2009 4 commits
  17. 04 Apr, 2009 2 commits
  18. 03 Apr, 2009 5 commits
  19. 30 Mar, 2009 3 commits
  20. 13 Mar, 2009 1 commit
  21. 27 Feb, 2009 2 commits
  22. 13 Jan, 2009 1 commit
  23. 07 Jan, 2009 2 commits
    • Jaswinder Singh Rajput's avatar
      firmware: convert e100 driver to request_firmware() · 9ac32e1b
      Jaswinder Singh Rajput authored
      Thanks to David Woodhouse for help.
      Signed-off-by: default avatarJaswinder Singh Rajput <jaswinderrajput@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9ac32e1b
    • Sam Ravnborg's avatar
      fix modules_install via NFS · 8b249b68
      Sam Ravnborg authored
      Rafael reported:
      
      I get the following error from 'make modules_install' on my test boxes:
      
        HOSTCC  firmware/ihex2fw
      /home/rafael/src/linux-2.6/firmware/ihex2fw.c:268: fatal error: opening dependency file firmware/.ihex2fw.d: Read-only file system
      compilation terminated.
      make[3]: *** [firmware/ihex2fw] Error 1
      make[2]: *** [_modinst_post] Error 2
      make[1]: *** [sub-make] Error 2
      make: *** [all] Error 2
      
      where the configuration is that the kernel is compiled on a build box
      with 'make O=<destdir> -j5' and then <destdir> is mounted over NFS read-only by
      each test box (full path to this directory is the same on the build box and on
      the test boxes).  Then, I cd into <destdir>, run 'make modules_install' and get
      the error above.
      
      The issue turns out to be that we when we install firmware pick
      up the list of firmware blobs from firmware/Makefile.
      And this triggers the Makefile rules to update ihex2fw.
      
      There were two solutions for this issue:
      1) Move the list of firmware blobs to a separate file
      2) Avoid ihex2fw rebuild by moving it to scripts
      
      As I seriously beleive that the list of firmware blobs should be
      done in a fundamental different way solution 2) was selected.
      Reported-and-tested-by: default avatar"Rafael J. Wysocki" <rjw@sisk.pl>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: David Woodhouse <dwmw2@infradead.org>
      8b249b68
  24. 05 Jan, 2009 3 commits
  25. 29 Dec, 2008 1 commit