1. 19 8月, 2015 2 次提交
  2. 15 8月, 2015 2 次提交
  3. 14 8月, 2015 5 次提交
    • P
      usb: chipidea: add tx/rx burst size configuration interface · 96625ead
      Peter Chen 提交于
      The user can adjust it through dts or platform data
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      96625ead
    • P
      usb: chipidea: add ahb burst configuration interface · 65668718
      Peter Chen 提交于
      The users can change it through dts or platform data if they
      want to change the default value.
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      65668718
    • P
      usb: chipidea: define stream mode disable for both roles · 8022d3d5
      Peter Chen 提交于
      The system bus and chipidea IP have different limitations for
      both host and device mode.
      For example, with below errata, we need to enable SDIS(Stream Disable
      Mode) at host mode. But we don't want it for device mode at the
      same system.
      
      TAR 9000378958
      Title: Non-Double Word Aligned Buffer Address Sometimes Causes Host to
      Hang on OUT Retry
      Impacted Configuration: Host mode, all transfer types
      Description:
      The host core operating in streaming mode may under run while sending
      the data packet of an OUT transaction. This under run can occur if
      there are unexpected system delays in fetching the remaining packet
      data from memory. The host forces a bad CRC on the packet, the device
      detects the error and discards the packet. The host then retries a Bulk,
      Interrupt, or Control transfer if an under run occurs according to the
      USB specification. During simulations, it was found that the host does
      not issue the retry of the failed bulk OUT. It does not issue any other
      transactions except SOF packets that have incorrect frame numbers.
      
      The second failure mode occurs if the under run occurs on an ISO OUT
      transaction and the next ISO transaction is a zero byte packet. The host
      does not issue any transactions (including SOFs). The device detects a
      Suspend condition, reverts to full speed, and waits for resume signaling.
      
      A third failure mode occurs when the host under runs on an ISO OUT and
      the next ISO in the schedule is an ISO OUT with two max packets of 1024
      bytes each. The host should issue MDATA for the first OUT followed by
      DATA1 for the second. However, it drops the MDATA transaction, and
      issues the DATA1 transaction.
      
      The system impact of this bug is the same regardless of the failure mode
      observed. The host core hangs, the ehci_ctrl state machine waits for the
      protocol engine to send the completion status for the corrupted
      transaction, which never occurs. No indication is sent to the host
      controller driver, no register bits change and no interrupts occur.
      Eventually the requesting application times out.
      
      Detailed internal behavior:
      The EHCI control state machine (ehci_ctrl) in the DMA block is responsible
      for parsing the schedules and initiating all transactions. The ehci_ctrl
      state machine passes the transaction details to the protocol block by
      writing the transaction information in to the TxFIFO. It then asserts
      the pe_hst_run_pkt signal to inform the host protocol state machine
      (pe_hst_state) that there is a packet in the TxFIFO.
      A tag of 0x0 indicates a start of packet with the data providing the
      following information:
      
      35:32 Tag
      31:30 Reserved
      29:23 Endpoint (lowest 4 bits)
      22:16 Address
      15:10 Reserved
      9:8 Endpoint speed
      7:6 Endpoint type
      5:6 Data Toggle
      3:0 PID
      The pe_hst_state reads the packet information and constructs the packet
      and issues it to the PHY interface.
      The ehci_ctrl state machine writes the start transaction information in
      to the TxFIFO as 0x03002910c for the OUT packet that had the under run
      error. However, it writes 0xC3002910C for the retry of the Out
      transaction, which is incorrect.
      The pe_hst_state enters a bus timeout state after sending the bad CRC
      for the packet that under ran. It then purges any data that was back
      filled in to the TxFIFO for the packet that under ran. The pe_hst_state
      machine stops purging the TxFIFO when it is empty or if it reads a
      location that has a tag of 0x0, indicating a start of packet command.
      
      The pe_hst_state reads 0xC3002910C and discards it as it does not decode
      to a start of packet command. It continues to purge the OUT data that
      has been pre-buffered for the OUT retry . The pe_hst_state detects the
      hst_packet_run signal and attempts to read the PID and address
      information from the TxFIFO. This location has packet data and so does
      not decode to a valid PID and so falls through to the PE_HST_SOF_LOAD
      state where the frame_num_counter is updated. The frame_num_counter
      is updated with the data in the TxFIFO. In this case, the data is
      incorrect as the ehci_ctrl state machine did not initiate the load.
      The hst_pe_state machine detects the SOF request signal and sends an
      SOF with the bad frame number. Meanwhile, the ehci_ctrl state machine
      waits indefinitely in the run_pkt state waiting for the completion
      status from pe_hst_state machine, which will never happen.
      
      The ISO failure case is similar except that there is no retry for ISO.
      The ehci_ctrl state machine moves to the next transfer in the periodic
      schedule. If the under run occurs on the last entry of the periodic
      list then it moves to the Async schedule.
      
      In the case of ISO OUT simulations, the next ISO is a zero byte OUT
      and again the start of packet command gets corrupted. The TxFIFO is
      empty when the hst_pe_state attempts to read the Address and PID
      information as the transaction is a zero byte packet. This results
      in the hst_pe_state machine staying in the GET_PID state, which means
      that it does not issue any transactions (including SOFs). The device
      detects a Suspend condition and reverts to full speed mode and waits
      for a Resume or Reset signal.
      
      The EHCI specification allows a Non-DoubleWord (32 bits) offset to
      be used as a current offset for Buffer Pointer Page 0 of the qTD.
      In Non-DoubleWord aligned cases, the core reads the packet data
      from the AHB memory, performs the alignment operation before writing
      it in to the TxFIFO as a 32 bit data word. An End Of Packet tag (EOP)
      is written to the TxFIFO after all the packet data has been written
      in to the TxFIFO. The alignment function is reset to Idle by the EOP
      tag. The corruption of the start of packet command arises because the
      packet buffer for the OUT transaction that under ran is not aligned
      to a DoubleWord, and hence no EOP tag is written to the TxFIFO. The
      alignment function is still active when the start packet information
      is written in to the TxFIFO for the retry of the bulk packet or for
      the next transaction in the case of an under run on an ISO. This
      results in the corruption of the start tag and the transaction
      information.
      
      Click for waveform showing the command 0x 0000300291 being written in
      to the TX FIFO for the Out that under ran.
      Click for waveform showing the command 0xC3002910C written to the
      TxFIFO instead of 0x 0000300291
      Versions affected: Versions 2.10a and previous versions
      How discovered: Customer simulation
      
      Workaround:
      1- The EHCI specification allows a non-DoubleWord offset to be used
      as a current offset for Buffer Pointer Page 0 of the qTD. However,
      if a DoubleWord offset is used then this issue does not arise.
      2- Use non streaming mode to eliminate under runs.
      
      Resolution:
      The fix involves changes to the traffic state machine in the
      vusb_hs_dma_traf block. The ehci_ctrl state machine updates the context
      information by encoding the transaction results on the
      hst_op_context_update signals at the end of a transaction. The signal
      hst_op_context_update is added to the traffic state machine, and the
      tx_fifo_under_ran_r signal is generated if the transaction results in
      an under run error. Click for waveform
      
      The traffic state machine then traverses to the do_eop states if the
      tx_fifo_under_ran error is asserted. Thus an EOP tag is written in to
      the TxFIFO as shown in this waveform .
      
      The EOP tag resets the align state machine to the Idle state ensuring
      that the next command written by the echi_ctrl state machine does not
      get corrupted.
      
      File(s) modified:
      RTL code fixed: …..
      Method of reproducing: This failure cannot be reproduced in the current
      test bench.
      Date Found: March 2010
      Date Fixed: June 2010
      Update information:
      Added the RTL code fix
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      8022d3d5
    • P
      usb: chipidea: introduce ITC tuning interface · df96ed8d
      Peter Chen 提交于
      ITC (Interrupt Threshold Control) is used to set the maximum rate at which
      the host/device controller will issue interrupts. The default value is 8 (1ms)
      for it. EHCI core will modify it to 1, but device mode keeps it as default
      value.
      
      In some use cases like Android ADB, it only has one usb request for each
      direction, and maximum payload data is only 4KB, so the speed is 4MB/s
      at most, it needs controller to trigger interrupt as fast as possible
      to increase the speed. The USB performance will be better if the interrupt
      can be triggered faster.
      
      Reduce ITC value is benefit for USB performance, but the interrupt number
      is increased at the same time, it may increase cpu utilization too.
      Most of use case cares about performance, but some may care about
      cpu utilization, so, we leave a platform interface for user.
      We set ITC as 1 (1 micro-frame) as default value which is aligned
      with ehci core default value.
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      df96ed8d
    • P
      usb: chipidea: add ttctrl.ttha control interface · 28362673
      Peter Chen 提交于
      The register of ttctrl.ttha describes like below:
      - Internal TT Hub Address Representation
      - RW
      - Default = 0000000b
      This field is used to match against the Hub Address field in QH & siTD
      to determine if the packet is routed to the internal TT for directly
      attached FS/LS devices. If the Hub Address in the QH or siTD does not
      match this address then the packet will be broadcast on the High Speed
      ports destined for a downstream High Speed hub with the address in the QH/siTD.
      
      In silicon RTL, this entry only affects QH and siTD, and the hub.addr at
      both QH and siTD are 0 in ehci core for chipidea (with hcd->has_tt = 1).
      
      So, for QH, if the "usage_tt" flag at RTL is 0, set CI_HDRC_SET_NON_ZERO_TTHA
      will not affect QH (with non-hs device); for siTD, set this flag
      will change remaining space requirement for the last transaction from 1023
      bytes to 188 bytes, it can increase the number of transactions within one
      frame, ehci periodic schedule code will not queue the packet if the frame space
      is full, so it is safe to set this flag for siTD.
      
      With this flag, it can fix the problem Alan Stern reported below:
      http://www.spinics.net/lists/linux-usb/msg123125.html
      And may fix Michael Tessier's problem too.
      http://www.spinics.net/lists/linux-usb/msg118679.html
      
      CC: stern@rowland.harvard.edu
      CC: michael.tessier@axiontech.ca
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      28362673
  4. 09 8月, 2015 1 次提交
  5. 06 8月, 2015 3 次提交
  6. 05 8月, 2015 3 次提交
    • R
      usb: gadget: add endpoint capabilities helper macros · 80e6e384
      Robert Baldyga 提交于
      Add macros useful while initializing array of endpoint capabilities
      structures. These macros makes structure initialization more compact
      to decrease number of code lines and increase readability of code.
      Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      80e6e384
    • R
      usb: gadget: add endpoint capabilities flags · 734b5a2a
      Robert Baldyga 提交于
      Introduce struct usb_ep_caps which contains information about capabilities
      of usb endpoints - supported transfer types and directions. This structure
      should be filled by UDC driver for each of its endpoints, and will be
      used in epautoconf in new ep matching mechanism which will replace ugly
      guessing of endpoint capabilities basing on its name.
      Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      734b5a2a
    • R
      usb: gadget: encapsulate endpoint claiming mechanism · cc476b42
      Robert Baldyga 提交于
      So far it was necessary for usb functions to set ep->driver_data in
      endpoint obtained from autoconfig to non-null value, to indicate that
      endpoint is claimed by function (in autoconfig it was checked if endpoint
      has set this field to non-null value, and if it has, it was assumed that
      it is claimed). It could cause bugs because if some function doesn't
      set this field autoconfig could return the same endpoint more than one
      time.
      
      To help to avoid such bugs this patch adds claimed flag to struct usb_ep,
      and  encapsulates endpoint claiming mechanism inside usb_ep_autoconfig_ss()
      and usb_ep_autoconfig_reset(), so now usb functions don't need to perform
      any additional actions to mark endpoint obtained from autoconfig as claimed.
      Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      cc476b42
  7. 31 7月, 2015 4 次提交
  8. 29 7月, 2015 8 次提交
  9. 10 7月, 2015 1 次提交
    • E
      cdc_ncm: Add support for moving NDP to end of NCM frame · 4a0e3e98
      Enrico Mioso 提交于
      NCM specs are not actually mandating a specific position in the frame for
      the NDP (Network Datagram Pointer). However, some Huawei devices will
      ignore our aggregates if it is not placed after the datagrams it points
      to. Add support for doing just this, in a per-device configurable way.
      While at it, update NCM subdrivers, disabling this functionality in all of
      them, except in huawei_cdc_ncm where it is enabled instead.
      We aren't making any distinction between different Huawei NCM devices,
      based on what the vendor driver does. Standard NCM devices are left
      unaffected: if they are compliant, they should be always usable, still
      stay on the safe side.
      
      This change has been tested and working with a Huawei E3131 device (which
      works regardless of NDP position), a Huawei E3531 (also working both
      ways) and an E3372 (which mandates NDP to be after indexed datagrams).
      
      V1->V2:
      - corrected wrong NDP acronym definition
      - fixed possible NULL pointer dereference
      - patch cleanup
      V2->V3:
      - Properly account for the NDP size when writing new packets to SKB
      Signed-off-by: NEnrico Mioso <mrkiko.rs@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a0e3e98
  10. 31 5月, 2015 1 次提交
  11. 28 5月, 2015 1 次提交
    • A
      usb: phy: add static inline wrapper for devm_usb_get_phy_by_node · 307c858b
      Arnd Bergmann 提交于
      The newly introduced devm_usb_get_phy_by_node function only has
      an extern declaration, but no alternative for the case that
      CONFIG_USB_PHY is disabled, which leads to a build error when
      it is used anyway:
      
      drivers/power/twl4030_charger.c: In function 'twl4030_bci_probe':
      drivers/power/twl4030_charger.c:648:23: error: implicit declaration of function 'devm_usb_get_phy_by_node' [-Werror=implicit-function-declaration]
          bci->transceiver = devm_usb_get_phy_by_node(
      
      This adds the wrapper in the same way that we have one for
      all other usb-phy API functions.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: e842b84c ("usb: phy: Add interface to get phy give of device_node.")
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      307c858b
  12. 26 5月, 2015 4 次提交
  13. 14 5月, 2015 1 次提交
    • H
      usb: add bus type for USB ULPI · 289fcff4
      Heikki Krogerus 提交于
      UTMI+ Low Pin Interface (ULPI) is a commonly used PHY
      interface for USB 2.0. The ULPI specification describes a
      standard set of registers which the vendors can extend for
      their specific needs. ULPI PHYs provide often functions
      such as charger detection and ADP sensing and probing.
      
      There are two major issues that the bus type is meant to
      tackle:
      
      Firstly, ULPI registers are accessed from the controller.
      The bus provides convenient method for the controller
      drivers to share that access with the actual PHY drivers.
      
      Secondly, there are already platforms that assume ULPI PHYs
      are runtime detected, such as many Intel Baytrail based
      platforms. They do not provide any kind of hardware
      description for the ULPI PHYs like separate ACPI device
      object that could be used to enumerate a device from.
      Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Acked-by: NDavid Cohen <david.a.cohen@linux.intel.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      289fcff4
  14. 29 4月, 2015 2 次提交
  15. 30 3月, 2015 2 次提交
反馈
建议
客服 返回
顶部