Rockchip socs often have some tiny number of muxes not controlled from
the core clock controller but through bits set in the general register
files. Add a clock-type that can control these as well, so that we
don't need to work around them being absent.
BUG=None
TEST=Build and boot on RK3399
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from git.kernel.org mmind/linux-rockchip.git v4.11-clk/next
commit cb1d9f6dda)
Change-Id: I79352c8596f4d03fde519cd544c9d509d84c3a66
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
For rockchip platform, we may need to support
NVMe bootup, so we need to add this flag so that
the rk partition layout could be able to find the
correct partition from parameter.
Change-Id: I3e0213df893bd137fa6d5fd0a0120cabeb6259e8
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
flag of emmc_disk was used to indicate that if the main
disk is for rockchip specific as we need to use rk specific
partition layout. But this name is vague and pointless since
the main disk could be sdmmc as we support sdmmc bootup.
Moreover, we could support more types of storage devices, for
instance, NVMe, UFS etc. Let's rename it to better reflect what
it is here.
Change-Id: Ibdeb4a930b97767d796ddfc050ee9d4d0ddeceb7
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Rockchip platform now not only use dw_mmc but also
the sdhci-of-arasan could be used as emmc. So we need
to add its dependency when setting emmc_disk flag.
Change-Id: I84f99657b874a15e60063b1b4ff94fd90cc191c3
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
We add debugfs entry in dwc3-rockchip probe, so need to remove
it when rmmod this driver module.
Change-Id: Ic0f7cf1386ffed8d492b0ba20625c63c549a7cdd
Signed-off-by: William Wu <wulf@rock-chips.com>
1.reparent vop's parent to vpll which vop is for hdmi.
2.reparent the other vop to cpll.
3.reparent others clk and set clk rate,
to slove some clks is dummy.
attention:
if the vopb is for hdmi,the vopb parent clk must be vpll
and the vopl parent clk is cpll or others plls.
if the vopl is for hdmi,the vopl parent clk must be vpll
and the vopb parent clk is cpll or other plls.
Change-Id: Ibfd05172c93f885f66deea9cec64d64e22174078
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
others clk change it's parent from cpll to dummy_cpll.
the vop's parent just vpll and cpll,
make sure each vop have it's own pll as parent.
Change-Id: Ia61e10918e14a69c053455018ddf0183ff15ea19
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
The driver selects NOP_USB_XCEIV, which can only be built-in if
USB_GADGET is either disabled or also built-in, so with USB_DWC2_PCI=y
and USB_GADGET=m, NOP_USB_XCEIV is also built-in and we get this link
error:
drivers/usb/built-in.o: In function `nop_set_peripheral':
(text+0x1927c): undefined reference to `usb_gadget_vbus_connect'
drivers/usb/built-in.o: In function `nop_gpio_vbus_thread':
(text+0x197a0): undefined reference to `usb_gadget_vbus_connect'
(text+0x19830): undefined reference to `usb_gadget_vbus_disconnect'
This adds the same dependency for the dwc2 driver to avoid that
broken configuration.
Change-Id: Ia3f3812443ec143665a9c0382b8f5a2e0c52e9eb
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit e43470dbdf)
As cat_printf() uses printf format strings in its parameters, adding
__printf attribute allows the compiler to detect at compile-time some
errors related to format strings (with -Wformat warning flag).
Change-Id: I3558d4a331acdf057c1daccbe86008ae0fd07216
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Acked-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit e135ab7405)
Done fixes and tested hsotg gadget's BDMA mode. Tested Control,
Bulk, Isoc, Inter transfers. Added code for isoc transfers,
removed unusable code, done minor fixes. Affected functions
and IRQ handlers:
- dwc2_hsotg_start_req(),
- dwc2_hsotg_ep_enable(),
- dwc2_hsotg_ep_queue(),
- dwc2_hsotg_handle_outdone(),
- GINTSTS_GOUTNAKEFF handler,
Removed 'has_correct_parity' flag from 'dwc2_hsotg_ep' struct.
Before this patch series, to set the data pid the DWC2 gadget
driver was toggling the even/odd until it match, then were
leaving it set. But now I have added mechanism to set pid and
excluded all code where this flag was set.
Change-Id: Iba211bde33c6bdb19617d69b5cff2923c37e0e20
Tested-by: John Keeping <john@metanate.com>
Signed-off-by: Vardan Mikayelyan <mvardan@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 837e9f00bf)
Reimplemented EP disabled interrupt handler and moved to
corresponding function.
This interrupt indicates that the endpoint has been disabled per
the application's request.
For IN endpoints flushes txfifo, in case of BULK clears DCTL_CGNPINNAK,
in case of ISOC completes current request.
For ISOC-OUT endpoints completes expired requests. If there is
remaining request starts it. This is the part of ISOC-OUT transfer
drop flow. When ISOC-OUT transfer expired we must disable ep to drop
ongoing transfer.
Change-Id: Id79f0ad59a3904a1f4951138463fd4cc0aa3b611
Tested-by: John Keeping <john@metanate.com>
Reviewed-by: Vahram Aharonyan <vahrama@synopsys.com>
Signed-off-by: Vardan Mikayelyan <mvardan@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit bd9971f0a1)
Incomplete ISO IN interrupt indicates one of the following conditions
occurred while transmitting an ISOC transaction.
- Corrupted IN Token for ISOC EP.
- Packet not complete in FIFO.
Incomplete ISO OUT indicates that there is at least one isochronous OUT
endpoint on which the transfer is not completed in the current
microframe.
The following actions will be taken:
In case of EP-IN
- Determine the EP
- Disable EP directly from this handler; when "Endpoint Disabled"
interrupt is received flush FIFO
In case of EP-OUT
- Determine the EP
- If target frame elapsed set DCTL_SGOUTNAK, unmask GOUTNAKEFF and
proceed as described in section 7.5.1 of DWC-HSOTG Programming Guide
Also added dwc2_gadget_target_frame_elapsed() helper function which
will be used in Incomplete ISO IN/OUT Interrupt handlers.
Change-Id: Id9832f7832eafc2c510f0d87bd38e4b820111352
Tested-by: John Keeping <john@metanate.com>
Signed-off-by: Vardan Mikayelyan <mvardan@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 381fc8f822)
NAKINTRPT interrupt is starting point for isoc-in transfer,
synchronization done with first in token received from host,
core asserts this interrupt when responds with 0 length data
to in token, received from host.
The first IN token is asynchronous for device - device does not
know when first one token will arrive from host. On first token
arrival HW generates 2 interrupts: 'in token received while FIFO
empty' and 'NAK'. NAK interrupt for ISOC in means that token has
arrived and ZLP was sent in response to that as there was no data
in FIFO. SW is basing on this interrupt to obtain frame in which
token has come and then based on the interval calculates next
frame for transfer.
OUTTKNEPDIS interrupt is starting point for isoc-out transfer,
synchronization done with first out token received from host
while corresponding ep is disabled.
For OUTs the reason is same - device does not know initial frame
in which out token will come. For this HW generates OUTTKNEPDIS
- out token is received while EP is disabled. Upon getting this
interrupt SW starts calculation for next transfer frame.
Change-Id: I178a19c9afbac314096e9a989966c3c778f95fce
Tested-by: John Keeping <john@metanate.com>
Signed-off-by: Vardan Mikayelyan <mvardan@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 5321922cb6)
Replaced repeating code with function call.
Starts next request from ep queue.
If queue is empty and ep is isoc
-In case of OUT-EP unmasks OUTTKNEPDIS.
OUTTKNEPDIS is masked in it's handler, so we need to unmask it here
to be able to do resynchronization.
Change-Id: Ib9d72c0ef728e145ac959218386c333f674ae0e2
Tested-by: John Keeping <john@metanate.com>
Signed-off-by: Vardan Mikayelyan <mvardan@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 41cc4cd271)
Increases and checks targeted frame number of current ep
if overrun happened, sets flag and masks with DSTS_SOFFN_LIMIT
Added following fields to struct dwc2_hsotg_ep
-target_frame: Targeted frame num to setup next ISOC transfer
-frame_overrun: Indicates SOF number overrun in DSTS
Change-Id: I80c0bc7bfe18e4e88b051795486c1cfccaa95b42
Tested-by: John Keeping <john@metanate.com>
Signed-off-by: Vardan Mikayelyan <mvardan@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 92d1635d78)
According DWC-OTG databook, "GOUTNakEff" is read only and can be
cleared only by "DCTL.CGOUTNak", but here we do not need to clear
it because DWC-OTG programming guide says that before disabling
any OUT endpoint, the application must enable Global OUT NAK mode,
so if this mode is enabled we can continue without this step.
Change-Id: If85da6787d585582712ca5d116db52caa70e72fc
Tested-by: John Keeping <john@metanate.com>
Signed-off-by: Vardan Mikayelyan <mvardan@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 6b58cb07a8)
This chunk is not needed here. There is no functionality
depend on this, so if no-op, I think we do not need to have
this interrupt unmasked.
Change-Id: I74a0861ce66e23888c001b7cf1833b7cce715362
Tested-by: John Keeping <john@metanate.com>
Signed-off-by: Vardan Mikayelyan <mvardan@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 7c01b99154)
Removed "ctrl |= DXEPCTL_USBACTEP" from
dwc2_hsotg_start_req() function because this
step is done in dwc2_hsotg_ep_enable().
Change-Id: I9675b30e1849c4f9d1ee099df44023dda8b5cf13
Tested-by: John Keeping <john@metanate.com>
Signed-off-by: Vardan Mikayelyan <mvardan@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 04cde4787d)
The gadget API function usb_ep_set_halt() expects the gadget to return
-EAGAIN if the ep is active. Add support for this behavior.
Otherwise this may break mass storage protocol if a STALL is attempted
on the endpoint.
Change-Id: I935ca97dfc5f6a97c2aeaef0afab97d7a0324a3a
Signed-off-by: Vahram Aharonyan <vahrama@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 51da43b555)
In case of DDMA mode we don't need to get an SOF interrupt so disable
the unmasking of SOF interrupt in DDMA mode.
Change-Id: I8a58bf26e8c9493a39e3f8ba6da1204d13b52127
Signed-off-by: Sevak Arakelyan <sevaka@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 907a444718)
In host slave mode, the core asserts the rxready, txfifoempty interrupts
that get serviced in the gadget irq handler. Prevent servicing of these
when not in the gadget mode of operation.
Change-Id: I821c48399f876de045649507435bf2a3e9cf4cc5
Signed-off-by: Vardan Mikayelyan <mvardan@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit ee3de8d750)
Replaced the WARN_ON with a check and return of -EINVAL in the
dwc2_hsotg_ep_enable function if ep0 is passed in.
Change-Id: Idf4bf147a52ff9dca294f76263438e41cc511cfc
Signed-off-by: Vahram Aharonyan <vahrama@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 8c3d609275)
The host/device mode set with dr_mode should be kept all the time,
not being changed to OTG in gadget setup (by overriding CFGUSB_FORCEDEVMODE
and CFGUSB_FORCEHOSTMODE bits).
Change-Id: I80037fb325d00cb302c223a65ef3ac628955fe08
Acked-by: John Youn <johnyoun@synopsys.com>
Tested-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Przemek Rudy <prudy1@o2.pl>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit ecd9a7ad45)
Fixes a static analysis issue in dwc2_complete_non_isoc_xfer_ddma(). The
qtd was being passed to a function after being freed. It was not being
used in the function so this doesn't fix any bugs. But it fixes up the
warning and makes the code safer by setting qtd to NULL and not using it
at all.
Change-Id: I5224d5b7854c23cc0d0931b5a131f93b9a2ce8c8
Reported-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 1fc6598949)
Move host core initialization and host channel routines into hcd.c. This
allows these functions to only be compiled in host-enabled driver
configurations (DRD or host-only).
Change-Id: Ib7ed69e977143de58a6055ecf417a48cf603cdff
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit b02038faa7)
Here, free memory is allocated using kmem_cache_zalloc. So, use
kmem_cache_free instead of kfree.
This is done using Coccinelle and semantic patch used
is as follows:
//<smpl>
@@
expression x,E,c;
@@
x =
\(kmem_cache_alloc\|kmem_cache_zalloc\|kmem_cache_alloc_node\)(c,...)
... when != x = E
when != &x
?-kfree(x)
+kmem_cache_free(c,x)
//</smpl>
Change-Id: I41fee7d3451196cc04d99104ecb7f4e7f84df3c9
Acked-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 9bbe91a1ea)
The microframe scheduler figured out exactly how many transfers we need
for a split transaction. Let's use this knowledge to know when to end
things.
Without this I found that certain devices would just keep responding
with tons of NYET resonses on their INT_IN endpoint. These would just
keep going and going and eventually we'd decide to terminate the
transfer (because the whole frame changed), but by that time the
scheduler would decide that we "missed" the start of the next transfer.
I can also imagine that if we blow past the end of our scheduled time we
may mess up other things that were scheduled to happen.
No known test cases are improved by this patch except that the scheduler
code doesn't yell about MISSES constantly anymore.
Change-Id: I743b8b121a3c41fdec33b463318f816654aa2bba
Acked-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 1479cb698a)
This totally reimplements the microframe scheduler in dwc2 to attempt to
handle periodic splits properly. The old code didn't even try, so this
was a significant effort since periodic splits are one of the most
complicated things in USB.
I've attempted to keep the old "don't use the microframe" schduler
around for now, but not sure it's needed. It has also only been lightly
tested.
I think it's pretty certain that this scheduler isn't perfect and might
have some bugs, but it seems much better than what was there before.
With this change my stressful USB test (USB webcam + USB audio + some
keyboards) crackles less.
Change-Id: Ifca7815fdff3301c0897aa4eb55e573384596344
Acked-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 9f9f09b048)
When setting up ISO and INT transfers dwc2 needs to specify whether the
transfer is for an even or an odd frame (or microframe if the controller
is running in high speed mode).
The controller appears to use this as a simple way to figure out if a
transfer should happen right away (in the current microframe) or should
happen at the start of the next microframe. Said another way:
- If you set "odd" and the current frame number is odd it appears that
the controller will try to transfer right away. Same thing if you set
"even" and the current frame number is even.
- If the oddness you set and the oddness of the frame number are
_different_, the transfer will be delayed until the frame number
changes.
As I understand it, the above technique allows you to plan ahead of time
where possible by always working on the next frame. ...but it still
allows you to properly respond immediately to things that happened in
the previous frame.
The old dwc2_hc_set_even_odd_frame() didn't really handle this concept.
It always looked at the frame number and setup the transfer to happen in
the next frame. In some cases that meant that certain transactions
would be transferred in the wrong frame.
We'll try our best to set the even / odd to do the transfer in the
scheduled frame. If that fails then we'll do an ugly "schedule ASAP".
We'll also modify the scheduler code to handle this and not try to
schedule a second transfer for the same frame.
Note that this change relies on the work to redo the microframe
scheduler. It can work atop ("usb: dwc2: host: Manage frame nums better
in scheduler") but it works even better after ("usb: dwc2: host: Totally
redo the microframe scheduler").
With this change my stressful USB test (USB webcam + USB audio +
keyboards) has less audio crackling than before.
Change-Id: I235e689c89be99a9f6ac406164c88e1d82e87260
Acked-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 9cf1a601d2)
As we start getting more exact about our scheduling it's becoming more
and more important to know exactly how far through the current frame we
are. This lets us make decisions about whether there's still time left
to start a new transaction in the current frame.
We'll add dwc2_hcd_get_future_frame_number() which will tell you what
the frame number will be a certain number of microseconds (us) from
now. We can use this information to help decide if there's enough time
left in the frame for a transaction that will take a certain duration.
This is expected to be used by a future change ("usb: dwc2: host:
Properly set even/odd frame").
Change-Id: I3cb39be7281e537696b6378e798c36ccea254739
Acked-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit fae4e82609)
The dwc2 scheduler (contained in hcd_queue.c) was a bit confusing in the
way it initted / kept track of which frames a QH was going to be active
in. Let's clean things up a little bit in preparation for a rewrite of
the microframe scheduler.
Specifically:
* Old code would pick a frame number in dwc2_qh_init() and would try to
pick it "in a slightly future (micro)frame". As far as I can tell the
reason for this was that there was a delay between dwc2_qh_init() and
when we actually wanted to dwc2_hcd_qh_add(). ...but apparently this
attempt to be slightly in the future wasn't enough because
dwc2_hcd_qh_add() then had code to reset things if the frame _wasn't_
in the future. There's no reason not to just pick the frame later.
For non-periodic QH we now pick the frame in dwc2_hcd_qh_add(). For
periodic QH we pick the frame at dwc2_schedule_periodic() time.
* The old "dwc2_qh_init() actually assigned to "hsotg->frame_number".
This doesn't seem like a great idea since that variable is supposed to
be used to keep track of which SOF the interrupt handler has seen.
Let's be clean: anyone who wants the current frame number (instead of
the one as of the last interrupt) should ask for it.
* The old code wasn't terribly consistent about trying to use the frame
that the microframe scheduler assigned to it. In
dwc2_sched_periodic_split() when it was scheduling the first frame it
always "ORed" in 0x7 (!). Since the frame goes on the wire 1 uFrame
after next_active_frame it meant that the SSPLIT would always try for
uFrame 0 and the transaction would happen on the low speed bus during
uFrame 1. This is irregardless of what the microframe scheduler
said.
* The old code assumed it would get called to schedule the next in a
periodic split very quickly. That is if next_active_frame was
0 (transfer on wire in uFrame 1) it assumed it was getting called to
schedule the next uFrame during uFrame 1 too (so it could queue
something up for uFrame 2). It should be possible to actually queue
something up for uFrame 2 while in uFrame 2 (AKA queue up ASAP). To
do this, code needs to look at the previously scheduled frame when
deciding when to next be active, not look at the current frame number.
* If there was no microframe scheduler, the old code would check for
whether we should be active using "qh->next_active_frame ==
frame_number". This seemed like a race waiting to happen. ...plus
there's no way that you wouldn't want to schedule if next_active_frame
was actually less than frame number.
Note that this change doesn't make 100% sense on its own since it's
expecting some sanity in the frame numbers assigned by the microframe
scheduler and (as per the future patch which rewries it) I think that
the current microframe scheduler is quite insane. However, it seems
like splitting this up from the microframe scheduler patch makes things
into smaller chunks and hopefully adds to clarity rather than reduces
it. The two patches could certainly be squashed. Not that in the very
least, I don't see any obvious bad behavior introduced with just this
patch.
I've attempted to keep the config parameter to disable the microframe
scheduler in tact in this change, though I'm not sure it's worth it.
Obviously the code is touched a lot so it's possible I regressed
something when the microframe scheduler is disabled, though I did some
basic testing and it seemed to work OK. I'm still not 100% sure why you
wouldn't want the microframe scheduler (presuming it works), so maybe a
future patch (or a future version of this patch?) could remove that
parameter.
Change-Id: I22486b060e24c06868a31ed593a1e38608fe1f02
Acked-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit fb616e3f83)
We'll use the new "scheduler verbose debugging" macro to log missed
SOFs. This is fast enough (assuming you configure it to use the ftrace
buffer) that we can do it without worrying about the speed hit. The
overhead hit if the scheduler tracing is set to "no_printk" should be
near zero.
Change-Id: I2b4fa9ec5b4ddf15f9ff28d7a876cb4e6341a55d
Acked-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 483bb2544c)
This no-op change splits code out of dwc2_schedule_periodic() into a
dwc2_do_reserve() function. This makes it a little easier to follow the
logic.
Change-Id: I24cd8d2718b150fdc0b4428e645c545b1d8dbeda
Acked-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 2d3f139810)
