- 26 Feb, 2016 10 commits
-
-
Vaibhav Hiremath authored
In poweroff() fn, we are shutting down SVC, so disable interrupt as well. Testing Done: Tested on DB3.5 platform. Signed-off-by:
Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Reviewed-by:
Michael Scott <michael.scott@linaro.org> Tested-by:
Greg Kroah-Hartman <gregkh@google.com>
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
Johan Hovold <johan@hovoldconsulting.com> Reviewed-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Johan Hovold authored
Move example module 1-4 to position 5, effectively renaming it 1-5. Signed-off-by:
-
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:
-
- 25 Feb, 2016 10 commits
-
-
Greg Kroah-Hartman authored
In kernel version 4.5, struct gpio_chip renamed the field 'dev' to 'parent' so handle this properly. Signed-off-by:
-
Greg Kroah-Hartman authored
Use the bundle device directly in gpio error messages instead of the gpio device, as they are the same pointer. This will make future gpio api changes much easier to handle. Signed-off-by:
-
Vaibhav Hiremath authored
If SVC coldboot fails or if of_platform_populate() fn fails, then state of device needs to be reverted. Importantly, if of_platform_populate() fails, then poweroff the SVC. Testing Done: Tested on DB3.5 platform. Signed-off-by:
-
Johan Hovold authored
Fix incomplete receive-data sanity checks. The payload size was never verified before parsing the uart header and neither was the uart-header data size verified against the actual payload size, something which could lead to information leaks when passing data beyond the payload buffer to the tty layer. Also remove the incorrect check against the maximum (tx-buffer) payload size. Reviewed-by:
Rui Miguel Silva <rui.silva@linaro.org> Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by:
-
Johan Hovold authored
Add dedicated serial-state request handler and add the missing sanity check on the incoming request. Reviewed-by:
-
Johan Hovold authored
Let's be well behaved and add a sanity check on the maximum greybus payload size to avoid underflow on the calculated buffer size. Reviewed-by:
-
Fabien Parent authored
The AP must enable the FCT flow of APBA once it has received the response from the AP that the connection between APBA and a module has been setted up. Disable the flow of FCT tokens when destroying connections. Signed-off-by:
Fabien Parent <fparent@baylibre.com> Reviewed-by:
-
Fabien Parent authored
Implement the control requests enabling/disabling the flow of FCT on APBA. Reviewed-by:
-
Fabien Parent authored
Add control requests to enable/disable the flow of unipro FCT tokens Reviewed-by:
-
Fabien Parent authored
In order to support mailbox-free control cport init on the bridges the AP must be able to enable/disable the flow of unipro fct tokens. Add a new API that will enable or disable on APBA the flow of fct tokens. Reviewed-by:
-
- 24 Feb, 2016 6 commits
-
-
Vaibhav Hiremath authored
Have a check inside all individual operational state change functions to check whether device is in same state, and if yes, then return immediately. Testing Done: Tested on DB3.5 platform. Signed-off-by:
-
Vaibhav Hiremath authored
If user switches from fw_flashing => off mode, then we do not need to do same things again, for example, clk_disable and wake/detect event, as while switching to fw_flashing, driver makes sure that device goes to off state and then brings back in fw_flashing state. Testing Done: Tested on DB3.5 platform. Signed-off-by:
-
Vaibhav Hiremath authored
Have a check inside all individual operational state change functions to check whether device is in same state, and if yes, then return immediately. Testing Done: Tested on DB3.5 platform Signed-off-by:
-
Jacopo Mondi authored
Rename the 'clock_mode' parameter to a more generic 'flags' in the csi bus configuration structure. Define flags value for continuous clock mode. Signed-off-by:
Jacopo Mondi <jacopo.mondi@linaro.org> Acked-by:
Laurent Pinchart <laurent.pinchart@linaro.org> Signed-off-by:
-
Jacopo Mondi authored
Add CSI configuration parameters to the configure_stream operation response. Currently, only the total number of lines in a second is used to configure the the AP-Bridge CSI transmitter, all other parameters (number of CSI data lanes, and CSI bus clock frequency) are kept hard-coded for two reasons: 1) We need to configure the CSI receiver on AP side accordingly to these settings, before sending them to APB1 CSI transmitter. 2) We cannot use the camera module provided parameters as-is, but use those information to compute the required bandwidth on the CSI bus, and configure the # of CSI data lanes, and the CSI bus clock speed in a way that satisfies that bandwidth requirement. Signed-off-by:
-
Greg Kroah-Hartman authored
We forgot to count the size of the uart send data message header when calculating the maximum size of the buffer that the uart driver could send in one chunk. This fixes the math and makes the variable a size_t to match the return value of the call to gb_operation_get_payload_size_max(); Reported-by:
Axel Haslam <ahaslam@baylibre.com> Signed-off-by:
-
- 23 Feb, 2016 2 commits
-
-
Johan Hovold authored
Remove unimplemented svc unique_id attribute from the documentation. This attribute made more sense when we thought we'd have an AP-module, unlike now when the AP and SVC are both part of the same frame. Signed-off-by:
-
Viresh Kumar authored
It might be of interest (to developers at least) to know when an interface is getting created or removed from the system. Interface creation message can further contain basic information about the interface, like its vid/pid and mfg/prod ids. Now, the interface is created by gb_interface_create(), which doesn't register the intf->dev to the kernel and so the print message is rather added to gb_interface_init() where we register the device with the kernel. A similar message is added to gb_interface_remove() only when the interface was earlier initialized. And this is how the output looks on real insertion/removal of the module: greybus 1-1: Interface added: VID=0x00000001, PID=0x00000001 greybus 1-1: DDBL1 Manufacturer=0x00000001, Product=0x00000001 ... greybus 1-1: Interface removed Signed-off-by:
-
- 18 Feb, 2016 4 commits
-
-
Greg Kroah-Hartman authored
This reverts commit 9b9b046af237f5674c2f7ca991dc62332b2d4041 Bryan wants more feedback first. Reported-by:
-
Vaibhav Agarwal authored
In case GB codec module is already removed, no action is required at the HW level. Thus, report SUCCESS to above layer. Reporting error to above layer will cause repeated trials and won't allow to update DPCM connections. Signed-off-by:
Vaibhav Agarwal <vaibhav.agarwal@linaro.org> Reviewed-by:
Mark Greer <mgreer@animalcreek.com> Signed-off-by:
-
Vaibhav Agarwal authored
In response to codec module removal, user space is reported about the event. In response to this, ALSA layer will update DAPM route and cleanup DAPM states. As a fallback mechanism, kernel can cleanup the DAPM state for codec module. But, this would cause immediate playback (first trial) to fail, since DSP is still in inconsistent state. To avoid such situation, a workqueue is scheduled for codec cleanup with timeout=50ms. Thus, normally it is expected from above layers to update routes and perform cleanup. However, fallback mechanism still holds good after 50ms. Signed-off-by:
-
Vaibhav Agarwal authored
Update params, sequence in response to changes in msm8994 helper APIs Signed-off-by:
-
- 17 Feb, 2016 7 commits
-
-
Rui Miguel Silva authored
The validation for a complete configured light is wrong and it is reworked to make sure that only when the light is ready, will handle request events. Signed-off-by:
-
Rui Miguel Silva authored
If register to v4l2 fails just mark the light as not having flash so in release we do not try to unregister. Signed-off-by:
-
Rui Miguel Silva authored
We do not need to check for channels and lights as they can never be NULL as a big memory array elements. Signed-off-by:
-
Alexandre Bailon authored
Throughput and requests per second calculations are broken for asynchronous request. Instead of calculate the throughput for each iteration, calculate it once at the end of the test. Signed-off-by:
Alexandre Bailon <abailon@baylibre.com> Signed-off-by:
-
Johan Hovold authored
Make sure to check for short transfers when retrieving the bridge cport count. Also clear the request buffer when allocating it. Signed-off-by:
-
Axel Haslam authored
All loopback transfer operations should have an identical header format in order to facilitate bandwidth and data movement analysis. Suggested-by:
-
Vaibhav Hiremath authored
Since parent driver (SVC) is controlling APBs directly, we do not need to bringup APBs in its own probe. Testing Done: Tested on EVT1.2. Signed-off-by:
-
- 15 Feb, 2016 1 commit
-
-
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:
Alex Elder <elder@linaro.org> Reviewed-by:
-
