1. 26 Feb, 2016 9 commits
    • Vaibhav Hiremath's avatar
      greybus: arche-platform: Set direction of wake/detect gpio in poweroff fn · 0786212d
      Vaibhav Hiremath authored
      With support of interrupt based mechanism, gpio is not longer set to
      output mode, so gpio_set_value won't work. So use
      gpio_direction_output() fn in poweroff(), while setting value on
      wake/detect line.
      
      Testing Done: Tested on DB3.5 platform.
      Signed-off-by: default avatarVaibhav Hiremath <vaibhav.hiremath@linaro.org>
      Reviewed-by: default avatarMichael Scott <michael.scott@linaro.org>
      Tested-by: default avatarMichael Scott <michael.scott@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      0786212d
    • Vaibhav Hiremath's avatar
      greybus: arche-platform: Assert wake/detect after SVC reset without delay · 16fe18ca
      Vaibhav Hiremath authored
      Since now driver supports interrupt based mechanism to read events
      from SVC over wake/detect line, no need to delay wake/detect assertion.
      We can assert wake/detect after SVC reset deassertion, so during boot
      itself SVC will start sending wake_out pulses.
      
      Testing Done: Tested on DB3.5 platform.
      Signed-off-by: default avatarVaibhav Hiremath <vaibhav.hiremath@linaro.org>
      Reviewed-by: default avatarMichael Scott <michael.scott@linaro.org>
      Tested-by: default avatarMichael Scott <michael.scott@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      16fe18ca
    • Vaibhav Hiremath's avatar
      greybus: arche-platform: Enable interrupt support on wake/detect line · f760bbfb
      Vaibhav Hiremath authored
      This patch enabled interrupt support on events received over wake/detect
      line. The driver follows below state machine,
      
      Default: wake/detect line is high (WD_STATE_IDLE)
      On Falling edge:
        SVC initiates boot (either cold/standby).
        On ES3, > 30msec = coldboot, else standby boot.
        Driver moves to WD_STATE_BOOT_INIT
      On rising edge (> 30msec):
        SVC expects APB to coldboot
        Driver wakes irq thread which kicks off APB  coldboot
        (WD_STATE_COLDBOOT_TRIG)
      On rising edge (< 30msec):
        Driver ignores it, do nothing.
      
      After coldboot of APB, HUB configuration work is scheduled after 2 sec,
      allowing enough time for APB<->SVC/Switch to linkup (in multiple
      iterations)
      
      Testing Done: Tested on DB3.5 platform.
      Signed-off-by: default avatarVaibhav Hiremath <vaibhav.hiremath@linaro.org>
      Reviewed-by: default avatarMichael Scott <michael.scott@linaro.org>
      Tested-by: default avatarMichael Scott <michael.scott@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      f760bbfb
    • Vaibhav Hiremath's avatar
      greybus: arche-platform: Add wake detect state based on functionality · 685353c1
      Vaibhav Hiremath authored
      If driver needs to process wake/detect events from SVC, by enabling
      interrupt support on wake/detect event, it becomes easier to maintain
      state of wake/detect line based on functionality.
      
      Testing Done: Tested on DB3.5 platform.
      Signed-off-by: default avatarVaibhav Hiremath <vaibhav.hiremath@linaro.org>
      Reviewed-by: default avatarMichael Scott <michael.scott@linaro.org>
      Tested-by: default avatarMichael Scott <michael.scott@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      685353c1
    • Vaibhav Hiremath's avatar
      greybus: arche-platform: Convert delayed work to do only hub3613 configuration · db5a3bca
      Vaibhav Hiremath authored
      This is preparation of interrupt handling support, where APB coldboot
      and wake/detect handling will be handled as response to wake/detect
      interrupt.
      Due to slower I2C write operations in HUB configuration, it is important
      to separate HUB configuration, and probably delay it after APB is
      cold booted.
      
      Note that delayed work will be scheduled from interrupt handler,
      in following patches.
      
      To satisfy build (and bisect), remove apb_cold_boot() fn, which will be
      added back in the patch where it gets used again.
      
      Testing Done: Tested on DB3.5 platform.
      Signed-off-by: default avatarVaibhav Hiremath <vaibhav.hiremath@linaro.org>
      Reviewed-by: default avatarMichael Scott <michael.scott@linaro.org>
      Tested-by: default avatarMichael Scott <michael.scott@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      db5a3bca
    • Vaibhav Hiremath's avatar
      greybus: arche-apb-ctrl: Remove extra delay in APB reset · 037a4028
      Vaibhav Hiremath authored
      With synchronization between SVC <=> AP over wake/detect line to
      bring APB's out of reset, we do not need any extra delays now.
      So remove it.
      
      Testing Done: Tested for DB3.5 and EVT1.2 platform.
      Signed-off-by: default avatarVaibhav Hiremath <vaibhav.hiremath@linaro.org>
      Reviewed-by: default avatarMichael Scott <michael.scott@linaro.org>
      Tested-by: default avatarMichael Scott <michael.scott@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      037a4028
    • Johan Hovold's avatar
      greybus: Documentation/sysfs: make 1-5 a 2x2 module · c8733c51
      Johan Hovold authored
      Make example module 1-5 a 2x2 module by adding a second, dummy
      interface.
      
      This is both an example of how a 2x2 module would be represented and
      also suggests what a dummy interface may look like.
      
      A 2x2 module has two child interface devices and a num_interfaces value
      of two.
      
      In this example, the secondary interface 1-5.6, is a dummy interface and
      therefore lacks the normal identifying attributes (e.g. UniPro DDBL1 and
      Ara ids). We may eventually add an interface_type attribute to
      facilitate distinguishing various interface types (there may be more
      than two).
      
      In the following tree, the bundle attributes and child devices have been
      left out:
      
      greybus1/
      ├── 1-2
      │   ├── 1-2.2
      │   │   ├── 1-2.2.1
      │   │   ├── 1-2.2.2
      │   │   ├── ddbl1_manufacturer_id
      │   │   ├── ddbl1_product_id
      │   │   ├── interface_id
      │   │   ├── product_id
      │   │   ├── serial_number
      │   │   ├── unique_id
      │   │   └── vendor_id
      │   ├── eject
      │   ├── module_id
      │   └── num_interfaces
      ├── 1-5
      │   ├── 1-5.5
      │   │   ├── 1-5.5.2
      │   │   ├── ddbl1_manufacturer_id
      │   │   ├── ddbl1_product_id
      │   │   ├── interface_id
      │   │   ├── product_id
      │   │   ├── serial_number
      │   │   ├── unique_id
      │   │   └── vendor_id
      │   ├── 1-5.6
      │   │   └── interface_id
      │   ├── eject
      │   ├── module_id
      │   └── num_interfaces
      └── 1-svc
      
      In this example there are two modules: 1-2 is a 1x2 module with one
      interface, and 1-5 is a 2x2 module with two interfaces of which the
      second (1-5.6) is a dummy interface.
      Signed-off-by: default avatarJohan Hovold <johan@hovoldconsulting.com>
      Reviewed-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      c8733c51
    • Johan Hovold's avatar
      greybus: Documentation/sysfs: move module 1-4 to position 5 · bd93d2a8
      Johan Hovold authored
      Move example module 1-4 to position 5, effectively renaming it 1-5.
      Signed-off-by: default avatarJohan Hovold <johan@hovoldconsulting.com>
      Reviewed-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      bd93d2a8
    • Johan Hovold's avatar
      greybus: Documentation/sysfs: add module devices · 8886c44f
      Johan Hovold authored
      Introduce module devices and rename interface and bundle devices.
      
      Greybus module devices correspond to physical modules and have one or
      more interfaces. Modules have an id that is identical to the id of their
      primary interface, which in turn is the interface with lowest numbered
      id. The module name is constructed from the bus and module id:
      
      	<bus_id>-<module_id>
      
      Interfaces and bundles are consequently renamed as
      
      	<bus_id>-<module_id>.<interface_id>
      
      and
      
      	<bus_id>-<module_id>.<interface_id>.<bundle_id>
      
      respectively.
      
      As before, interface ids (and therefore in a sense now also module ids)
      correspond to physical interface positions on the frame.
      
      Modules have the following attributes:
      
      	eject
      	module_id
      	num_interfaces
      
      where module_id is the id of the module and num_interface the number of
      interfaces the module has.
      
      Note that the interface ids of a module's interfaces are expected to be
      <module_id>, <module_id + 1>, ..., <module_id + num_interfaces - 1>.
      
      Writing a non-zero argument to eject cleanly shuts down and unregisters
      all of the module interfaces before ejecting the module.
      
      The example sysfs tree now looks as follows with the second bus
      (APBridgeA) left out:
      
      greybus1/
      ├── 1-2
      │   ├── 1-2.2
      │   │   ├── 1-2.2.1
      │   │   │   ├── bundle_class
      │   │   │   ├── bundle_id
      │   │   │   └── state
      │   │   ├── 1-2.2.2
      │   │   │   ├── bundle_class
      │   │   │   ├── bundle_id
      │   │   │   └── state
      │   │   ├── ddbl1_manufacturer_id
      │   │   ├── ddbl1_product_id
      │   │   ├── interface_id
      │   │   ├── product_id
      │   │   ├── serial_number
      │   │   ├── unique_id
      │   │   └── vendor_id
      │   ├── eject
      │   ├── module_id
      │   └── num_interfaces
      ├── 1-4
      │   ├── 1-4.4
      │   │   ├── 1-4.4.2
      │   │   │   ├── bundle_class
      │   │   │   ├── bundle_id
      │   │   │   ├── gpbridge0
      │   │   │   │   ├── gpio
      │   │   │   │   │   └── gpiochip490
      │   │   │   │   └── i2c-4
      │   │   │   └── state
      │   │   ├── ddbl1_manufacturer_id
      │   │   ├── ddbl1_product_id
      │   │   ├── interface_id
      │   │   ├── product_id
      │   │   ├── serial_number
      │   │   ├── unique_id
      │   │   └── vendor_id
      │   ├── eject
      │   ├── module_id
      │   └── num_interfaces
      └── 1-svc
          ├── ap_intf_id
          ├── eject
          └── endo_id
      
      where greybus1 is a bus; 1-svc the svc; 1-2, and 1-4 are modules; 1-2.2
      and 1-4.4 are (primary) interfaces; and 1-2.2.1, 1-2.2.2, and 1-4.4.2
      are bundles.
      
      Note that the svc eject attribute may eventually be renamed force_eject.
      Signed-off-by: default avatarJohan Hovold <johan@hovoldconsulting.com>
      Reviewed-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      8886c44f
  2. 25 Feb, 2016 10 commits
  3. 24 Feb, 2016 6 commits
  4. 23 Feb, 2016 2 commits
  5. 18 Feb, 2016 4 commits
  6. 17 Feb, 2016 7 commits
  7. 15 Feb, 2016 2 commits
    • Viresh Kumar's avatar
      greybus: manifest: Parse cports (within a bundle) in the order from manifest blob · 4a7908cb
      Viresh Kumar authored
      The order in which cports (of a bundle) are present in the manifest blob
      is important for gbsim, as it allocates hd_cport_id's for them
      sequentially.
      
      For example, if there are two cports (1 and 2, in order 1->2) present in
      a bundle in the manifest blob, then gbsim allocates hd_cport_id X and
      X+1 for them. This is done on the assumption that kernel will do the
      same. Though it shouldn't have had any such assumptions since the
      beginning.
      
      But with a recent patch that sequence is changed, and it broke the
      assumption gbsim had.
      
      While parsing the manifest blob, the cports within a bundle are now
      moved to another list using list_move() and then they are picked one by
      one from the HEAD of the list.
      
      list_move() first deletes the node and then adds it to HEAD as it uses
      list_add() and not list_add_tail(). And that reverses the order in which
      the cports were present in the original list.
      
      And because of this, the messages destined for cport 1 are delivered to
      cport 2 and the ones for cport 2 are delivered to cport 1.
      
      In order to get gbsim working with greybus, keep the cport list in the
      order in which they were present in manifest, by replacing list_move()
      with list_move_tail().
      
      Its a trivial patch and shouldn't have any side effects on the working
      of greybus with nuttx.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: default avatarAlex Elder <elder@linaro.org>
      Reviewed-by: default avatarJohan Hovold <johan@hovoldconsulting.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      4a7908cb
    • Laurent Pinchart's avatar
      greybus: camera: Don't configure CSI TX in test only mode · 640924d2
      Laurent Pinchart authored
      When the GB_CAMERA_CONFIGURE_STREAMS_TEST_ONLY flag is set by the caller
      the configure streams operation should only test the requested settings
      without modifying the hardware state. This applies for both the module,
      the UniPro links power modes and the AP bridge settings. Return early
      when the flag is set to avoid modifying the AP bridge CSI TX settings.
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Reviewed-by: default avatarGjorgji Rosikopulos <grosikopulos@mm-sol.com>
      Tested-by: default avatarJacopo Mondi <jacopo.mondi@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      640924d2