- 29 Jun, 2016 3 commits
-
-
Johan Hovold authored
This reverts commit 426237c515b42b9f06d9a2b1021a6d2c4d440c51. Someone decided that all use of spin_lock_irq was to be considered a bug and went on a search-and-replace type "bug-fixing" spree last week. This is however just plain wrong. Using spin_lock_irq is perfectly fine in paths were interrupts have not been disabled, and this is in fact even preferred over the lazy approach of always using spin_lock_irqsave instead of understanding the code that is being written or modified. All current uses of spin_lock_irq have already been vetted in this respect. Also note that it is only used in functions that may sleep, that is, in functions that must not be called with interrupts disabled in the first place. Signed-off-by:
Johan Hovold <johan@hovoldconsulting.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@google.com>
-
Sandeep Patil authored
The input device was added before to handle the key(s) connected directly to SVC, which is not the case anymore. So, this change removes the gb_svc_key_event() operation and the corresponding input device code with it. Testing Done: Boot tested and tried module insert/removal through AraManager Change-Id: Iaa541d4aefb5c0ed16caaa39450029de35d7c228 Signed-off-by:
Sandeep Patil <sspatil@google.com> Signed-off-by:
-
Viresh Kumar authored
It was added in 4.6 and is required for one of the use case, copy it. Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
- 24 Jun, 2016 13 commits
-
-
Johan Hovold authored
Add support for Greybus CPort flags that are sent to the bridge through a new USB vendor request when enabling a CPort as part of connection establishment. Currently the Greybus control and high-priority connection flags are recognised and forwarded to APBA. Reviewed-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Johan Hovold authored
Add connection flag to indicate that a connection has high priority. For the SVC and control connections this may be used by the host-device driver as a hint to allocate dedicated DMA channels or to use polling to avoid message congestion. We also allow drivers to set this flag on their connections, even though we currently have no use case for this (and the host-device driver is again free to ignore it). Note that this mechanism can be used to indicate also high-bandwidth connections (e.g. wanting larger buffers or dedicated endpoints), but that that should be done using a separate high-bandwidth flag rather than overloading the high-priority flag. Reviewed-by:
-
Johan Hovold authored
Prevent drivers from specifying core flags (currently only GB_CONNECTION_FLAG_CONTROL) when creating connections. Reviewed-by:
-
Johan Hovold authored
Add a flag argument to the host-device cport_enable callback that can be used to provide hints about the connection being created (e.g. connection priority). Reviewed-by:
-
Evgeniy Borisov authored
Add support for greybus RAW data format. Greybus RAW data formats starts from 0x80. Signed-off-by:
Evgeniy Borisov <eborisov@mm-sol.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@linaro.org> Reviewed-by:
Gjorgji Rosikopulos <grosikopulos@mm-sol.com> Signed-off-by:
-
David Lin authored
The return statement immediately after the BUG_ON of the gbcodec_write() call is added by mistake. It's not causing any errors right now due to that gbcodec_reg is currently not being used. Testing Done: - Audio playback on EVT2 Signed-off-by:
David Lin <dtwlin@google.com> Reviewed-by:
Mark Greer <mgreer@animalcreek.com> Signed-off-by:
-
Jeffrey Carlyle authored
We know that it is a bad idea to explicitly enable IRQs when we don't don't know if they were already off before we disabled, so switch to the save _irqsave and _irqrestore functions. Ultimately, we need to review places in the Greybus drivers where IRQs are disabled and remove unnecessary instances. This is only an interim step. This code will never run from hard irq context, as it is already taking mutex in the path. Testing done: booted EVT2.0, ran suspend/resume test app with a period of 20s for a few dozen cycles. Signed-off-by:
Jeffrey Carlyle <jcarlyle@google.com> Signed-off-by:
-
Viresh Kumar authored
The greybus SVC core handles events from the SVC serially today. In some cases the SVC operations may take too long, for example trying to activate a dummy interface. If another interface receives a mode-switch mailbox event in that time, the SVC core wouldn't be able to process it in quickly enough and bootrom driver will print following error: bootrom 1-3.3.1: Timed out waiting for Interface Mode Switch from the Module This can be reproduced easily by attaching a 2x2 module along with any other normal module like camera or speaker, and doing a unipro_reset from userspace. The logs suggest this time to be around 6-7 seconds in most of the cases. Attaching multiple modules with dummy interfaces may make this worst. Lets increase the timeout from 5 to 10 seconds for now, also add a FIXME for the same. Testing Done: Tested on EVT 2.0 with camera and a 2x2 module. Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by:
-
Viresh Kumar authored
Rename NEXT_REQ_TIMEOUT_J to NEXT_REQ_TIMEOUT_MS and store the timeout in milliseconds instead of jiffies. Suggested-by:
Alex Elder <alex.elder@linaro.org> Signed-off-by:
-
Viresh Kumar authored
The timeout message is very generic today and there are several requests we can be timing out waiting for. Update bootrom driver to also track the next expected request and enhance the error message based on that to confirm the request we timed out waiting for. Signed-off-by:
-
Bryan O'Donoghue authored
The current printout on a TimeSync ping doesn't actually contain the word greybus and uses the word ping-time in the print string, something that appears nowhere in our official documentation on this feature. This patch changes the format string to contain 'greybus' and 'frametime' to bring the TimeSync printout more in-line with other greybus kernel log strings. before: timesync ping-time: ap=8632564 1-svc=8630712 greybus1=8633031 1-8.8=8633026 after: greybus frametime: ap=8632564 1-svc=8630712 greybus1=8633031 1-8.8=8633026 Signed-off-by:
-
Bryan O'Donoghue authored
Remember to initialize the TimeSync ping fields to zero so that if a timesync_get_last_event() returns an error - we display a FrameTime that is obviously incorrect. Signed-off-by:
-
Joel Porquet authored
Add support for the new Log class/protocol. This protocol allows modules to send their internal logging messages to the AP in order to make module debugging easier. The protocol is, for now, composed a single module-initiated request. This request contains a message and associated length. The message is integrated in the kernel log with dev_dbg(). In order to be displayed with 'dmesg', the following command needs to be entered first: $ echo "file log.c +p" > /sys/kernel/debug/dynamic_debug/control The major portion of this file was initially written by Greg KH. Signed-off-by:
Joel Porquet <porquet_joel@projectara.com> Signed-off-by:
-
- 23 Jun, 2016 8 commits
-
-
Viresh Kumar authored
spin_[un]lock_irq() routines should be used carefully as they things can go wrong, if they are mixed with spin_lock_irqsave() or other variants. The main problem is that spin_[un]lock_irq() routines doesn't check if the IRQs are already disabled/enabled on the local CPU and so spin_unlock_irq() will forcefully enable interrupts for example. This may not work well, if some other code was relying on interrupts being disabled. Use spin_lock_irqsave() and spin_unlock_restore() instead. This patch doesn't claim that it fixes the JIRA completely, but the issue was harder to reproduce for some iterations after this, which was quite easy to reproduce earlier on. Tested on EVT 2.0 with lots of debug patches to kernel and greybus. Signed-off-by:
-
Viresh Kumar authored
spin_[un]lock_irq() routines should be used carefully as they things can go wrong, if they are mixed with spin_lock_irqsave() or other variants. The main problem is that spin_[un]lock_irq() routines doesn't check if the IRQs are already disabled/enabled on the local CPU and so spin_unlock_irq() will forcefully enable interrupts for example. This may not work well, if some other code was relying on interrupts being disabled. Use spin_lock_irqsave() and spin_unlock_restore() instead. This patch doesn't claim that it fixes the JIRA completely, but the issue was harder to reproduce for some iterations after this, which was quite easy to reproduce earlier on. Tested on EVT 2.0 with lots of debug patches to kernel and greybus. Signed-off-by:
-
Viresh Kumar authored
spin_[un]lock_irq() routines should be used carefully as they things can go wrong, if they are mixed with spin_lock_irqsave() or other variants. The main problem is that spin_[un]lock_irq() routines doesn't check if the IRQs are already disabled/enabled on the local CPU and so spin_unlock_irq() will forcefully enable interrupts for example. This may not work well, if some other code was relying on interrupts being disabled. Use spin_lock_irqsave() and spin_unlock_restore() instead. This patch doesn't claim that it fixes the JIRA completely, but the issue was harder to reproduce for some iterations after this, which was quite easy to reproduce earlier on. Tested on EVT 2.0 with lots of debug patches to kernel and greybus. Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 469fbe5da0229edcb42aa08bef8e10feaa37e6d7. It isn't correct in places. Reported-by:
Gjorgji Rosikopulos <rosikopulos_gjorgji@projectara.com> Signed-off-by:
-
Bryan O'Donoghue authored
gb_timesync_svc_teardown() is called from gb_timesync_svc_del() and issues a command to a remote Interface to switch off its timers. The lock ordering is TimeSync => Interface in this case. However gb_module_del() takes an Interface lock then calls gb_interface_del() => gb_timesync_svc_del() in this case the lock ordering is Interface => TimeSync. This patch fixes by removing the taking of the Interface mutex in gb_interface_timesync_do_something(). If an Interface is present in the TimeSync linked-list - it is by definition intf->enabled. Reported-by:
Rui Miguel Silva <rui.silva@linaro.org> Signed-off-by:
-
Viresh Kumar authored
spin_[un]lock_irq() routines should be used carefully as they things can go wrong, if they are mixed with spin_lock_irqsave() or other variants. The main problem is that spin_[un]lock_irq() routines doesn't check if the IRQs are already disabled/enabled on the local CPU and so spin_unlock_irq() will forcefully enable interrupts for example. This may not work well, if some other code was relying on interrupts being disabled. Use spin_lock_irqsave() and spin_unlock_restore() instead. This patch doesn't claim that it fixes the JIRA completely, but the issue was harder to reproduce for some iterations after this, which was quite easy to reproduce earlier on. Tested on EVT 2.0 with lots of debug patches to kernel and greybus. Signed-off-by:
-
Viresh Kumar authored
This reverts commit 9b891f4fda8dfd6c1d8dc16479c5f6d418a9ccc7. We discussed this over the other thread, [PATCH 0/2] Improve watchdog's implementation a bit, and decided that we shouldn't be trying to hide the watchdog reboot problem by using such patches, rather we should make sure they occur consistently so that the real problem can be fixed. Signed-off-by:
-
Michael Scott authored
When building greybus against a 3.18 kernel the following error is generated: light.c:205:9: error: implicit declaration of function 'led_sysfs_is_disabled' [-Werror=implicit-function-declaration] led_sysfs_is_disabled was not added until 3.19 kernel cycle Verification: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/include/linux/leds.h?h=linux-3.18.y (no function led_sysfs_is_disabled defined here) Testing Done: - Successfully built greybus for 3.18 kernel Signed-off-by:
Michael Scott <michael.scott@linaro.org> Signed-off-by:
-
- 21 Jun, 2016 2 commits
-
-
Vaibhav Hiremath authored
It is believed that excessive serial messages from greybus on suspend/resume is leading to watchdog bite. There is still discussion going on whether ratelimiting prints would really fix anything, except it may reduce traffic on serial console and probably bring out real issues in the front. So in order to meet the alpha requirement, we all decided to get ratelimit change "as a TEMP fix" and decide later whether we should revert back once we get proper suspend/resume implementation. Please follow the discussion on Jira card SW-6261. Testing Done: Build tested against ara/main branch. Signed-off-by:
Vaibhav Hiremath <vaibhav.hiremath@linaro.org> Reviewed-by:
Konstantin Buhchev <buhchev_konstantin@projectara.com> Signed-off-by:
-
Rui Miguel Silva authored
Right now greybus sdio uses the greybus operation_sync to transfer data, this will imply an extra memcpy at greybus core that we can avoid. Also with this change we remove the need for an extra buffer to store intermediate copy. So, let us create the operation and do the memory operations in the sdio driver. Signed-off-by:
-
- 16 Jun, 2016 8 commits
-
-
Viresh Kumar authored
This is what we are doing elsewhere: - Send enable/create trace events after enabling/creating stuff. - Send disable/remove trace events before disabling/removing stuff. This wasn't followed in a same way while disabling connections. Fix it. Compile tested. Signed-off-by:
-
Viresh Kumar authored
This will make it consistent with any other character devices we have for greybus and let us identify greybus character devices easily. Compiled tested only. Signed-off-by:
-
Bryan O'Donoghue authored
We need to make sure we adequately cancel and quiesce any scheduled TimeSync synchronization operations in the case of greybus.ko being yanked out of memory i.e. when doing an EHCI runtime suspend or just a plain rmmod. The scenario is a new TimeSync sync operation has been scheduled. Next gb_timesync_svc_remove() runs. In this case we should terminate any scheduled work, terminate our ktime tracking timer and state transition to GB_TIMESYNC_STATE_INVALID to ensure no other context may schedule any new TimeSync operations. Signed-off-by:
-
Bryan O'Donoghue authored
Analysing a backtrace associated with the current EHCI runtime suspend code has highlighted several places where its perfectly valid to make a transition to GB_TIMESYNC_STATE_INACTIVE when not already in the GB_TIMESYNC_STATE_INIT state, for example failure to issue a TimeSync enable command to the SVC can and should legitimately call gb_timesync_teardown() - at this point the state will be GB_TIMESYNC_STATE_WAIT_SVC and it's legitimate and desirable to transition to the INACTIVE state in this case. This patch fixes by removing the restrictive and incorrect restriction on the transition to INACTIVE only being valid when state == GB_TIMESYNC_STATE_INIT. Signed-off-by:
-
Bryan O'Donoghue authored
There is a scenario where gb_timesync_svc_remove() can run, attain a mutex and call cancel_delayed_work_sync(). In the meantime a worker may already be running and trying to attain the same mutex but will never do so as the gb_timesync_svc_remove() path is holding the mutex and waiting on the delayed_work_sync() to complete - leading to deadlock. This patch addresses by calling the cancel_delayed_work_sync() before locking the relevant mutex. Reported-by:
Vaibhav Agarwal <vaibhav.agarwal@linaro.org> Signed-off-by:
-
Viresh Kumar authored
Add license and copyright header to the firmware.c test application. Signed-off-by:
-
Viresh Kumar authored
We should be checking if any of the bundles contains a CPort with its id set to the special value of '0', which is reserved for control CPort. Discard the bundle in that case. Signed-off-by:
-
Vaibhav Hiremath authored
In gb_svc_input_create() fn, on failure, wrong pointer was being passed to input_free_device(). Correct it. svc->input gets initialized only on successful return of this fn, so it is absolutely wrong to pass svc->input to input_free_device(). Testing Done: Tested on EVT2.0 platform. Signed-off-by:
-
- 15 Jun, 2016 3 commits
-
-
Laurent Pinchart authored
Creating the data connection at probe time makes it impossible to support multiple inserted camera modules as they would all try to establish a data connection to the same CPort on the AP side. Create and destroy the data connection when configuring the streams instead, as a single module can be streaming at a time. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Laurent Pinchart authored
When the module is in the configured state, an attempt to change the configuration must first tear down the data connection to update its parameters, as the APB1 bridge doesn't support modifying the CSI transmitter configuration when it is already started. Signed-off-by:
-
Laurent Pinchart authored
When the camera pipeline can't be configured due to a failure of one of the components (failure to start the CSI transmitter for instance), components that have already been setup for video streaming need to be set back to a quiescient state. This is especially important to ensure that a stream configuration failure won't keep the UniPro links in high speed mode forever. Signed-off-by:
-
- 14 Jun, 2016 1 commit
-
-
Viresh Kumar authored
gb_svc_del() can be called during removal of gb-es2.ko module as well, and in that case we would like to properly shutdown all modules and interfaces as USB is still alive. This requires that we don't disable the svc connection, at least for tx, as that will be used while removing modules and interfaces. Disable only rx to begin with, as we shouldn't be handling any requests from the SVC. Disable tx only after all the users of svc connection are gone. Tested on EVT 2.0 by remove gb-es2.ko module. There are still few errors, specially while quiescing the connections (-22), but not that many. Signed-off-by:
-
- 13 Jun, 2016 1 commit
-
-
Viresh Kumar authored
We are using the mutex from gb_camera_cleanup(), which can get called even before the mutex is initialized. Fix it by initializing the mutex early enough. Signed-off-by:
-
- 10 Jun, 2016 1 commit
-
-
Viresh Kumar authored
This is used only to check if an existing connection already uses the cport_id or not and doesn't really need to return pointer to the connection. While at it, also rename it to suit its purpose. Signed-off-by:
-
