This adds force abnormal ohci relinquish port owner
and back to ehci on rk3288 SoC.
Change-Id: I33be55c08762be7e8a239f741a8c8dbb28522306
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Add a quirk to support rockchip relinquishing port from abnormal ohci
to ehci when FS/LS devices plug in.
To support this function, the rockchip-relinquish-port property must be
specified in ehci node of dt.
Change-Id: I91b58905132282ef2a836d54a1c7ace1e334d119
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
This reverts commit 0fd1853df0.
We found this commit just work well for HS devices, however,
ehci_hub_control will set port owner to companion according line
status bits when FS/LS device is plugged in, so revert this one
and introduce a new workaround.
Change-Id: Ifa856620672191c845abc53a76370cd5bf4097dc
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
We need a luxury timeout once needing some extra time to
wait for flushing cache.
Change-Id: I8cd4015f30fa45cacdb984f0461b1ad8ee6cba7d
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
SADs may span multiple CEA audio data blocks in the EDID.
CEA-861-E says:
"The order of the Data Blocks is not constrained. It is also possible
to have more than one of a specific type of data block if necessary to
include all of the descriptors needed to describe the sink’s capabilities."
Each audio data block can carry up to 10 SADs, whereas the ELD SAD limit
is 15 according to HDA 1.0a spec. So we should support at least two data
blocks. And apparently some devices take a more liberal interpretation
and stuff only one SAD per data block even when they would fit into one.
So let's try to extract all the SADs we can fit into the ELD even when
they span multiple data blocks.
While at it, toss in a comment to explain the 13 byte monitor name
string limit which confused me at first.
Cc: Arturo Pérez <artur999555@gmail.com>
Tested-by: Arturo Pérez <artur999555@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94197
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1457554066-8739-1-git-send-email-ville.syrjala@linux.intel.com
(cherry picked from commit 7c01878254)
Change-Id: I18c5c64b69802a6a50de624d55b4b5217943b76e
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
some log is so boring, set print level more high.
Change-Id: I8cfe16f535718a130fa03ee7173e4ef325239e06
Signed-off-by: dalon.zhang <dalon.zhang@rock-chips.com>
If a display support HDMI2.0, it must support SCDC or YCbCr420.
So we check the connector->scdc_present and mode->flags to
check the connected display is HDMI 2.0.
Change-Id: I3b868d43791089fcdef77f99ec90396553008b9a
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.
This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.
In case of I915 driver, this patch checks the connector->display_info
to check if the connected display is HDMI 2.0.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <jose.abreu@synopsys.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
(am from https://patchwork.kernel.org/patch/9641449)
Change-Id: I364cd0aed7eea0384ea9eddfff20c3fa86eb9ba2
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
This patch uses the resource-managed to add the devfreq device.
This function will make it easy to handle the devfreq device.
- struct devfreq *devm_devfreq_add_device(struct device *dev,
struct devfreq_dev_profile *profile,
const char *governor_name,
void *data);
Conflicts:
drivers/devfreq/rk3399_dmc.c
Change-Id: I2ba2779a1b944931dc240f0593824f0316d11985
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
(cherry picked from commit 927b75a628)
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/devfreq/rk3399_dmc.ko | grep alias
$
After this patch:
$ modinfo drivers/devfreq/rk3399_dmc.ko | grep alias
alias: of:N*T*Crockchip,rk3399-dmcC*
alias: of:N*T*Crockchip,rk3399-dmc
Change-Id: I4bffd86067bb487619ce8365532123938a0ca964
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
(cherry picked from commit 2f3f1a261c)
Current code uses devm_regulator_get() in .probe so a regulator_put() will
be automatically called when unload the module. Remove the explictly
regulator_put() call and then we can also remove rk3399_dmcfreq_remove().
Change-Id: I56a62a76f06403aff9ad0478e7701862084a90b3
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
(cherry picked from commit da4a64481b)
dw-hdmi introduced insert_pcuv bit in version 2.10a. When
set (1'b1), this bit enables the insertion of the PCUV
(Parity, Channel Status, User bit and Validity) bits on the
incoming audio stream (support limited to Linear PCM audio).
Change-Id: Ib12a50bf7064ac78dbf143f1ea35d7f68f861877
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
set rtc stopped by default, start rtc in rtc device probe.
add rtc node, whether RTC need to initialize.
Change-Id: Ifab269786f316d33149a50a18e23af1b6206d57d
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Reset_control_assert/reset_control_deassert will not check whether
the incoming pointer is NULL, so we need to check it before using it.
Change-Id: Ib2aeeefcb2d5d7429031bc21bf7e3df1d897a6c9
Signed-off-by: WeiYong Bi <bivvy.bi@rock-chips.com>
Since rga is a dma-coherent device, we have to use drm bus
device to call sync api.
Change-Id: Ia12062293fabba083c8ab9c4f7457e3167807bb9
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
The USB20_HOST_EN and USB20_OTG_EN configs are used
for rockchip dwc2 legacy driver, they are not needed
for dwc_otg_310 driver.
Change-Id: I4c16f0be5276b3c07429ab88cb063508b34ce007
Signed-off-by: William Wu <wulf@rock-chips.com>
This adds enable dwc_otg_310 driver for dwc otg and host.
Change-Id: I779c663992b270015515d45a94e3fa4187368a93
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
to fix up the display shaking when uboot to kernel show.
Change-Id: I5f85028921d76a2dea752aafe7420b05b041bc8e
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
GSL3673 is a touchscreen device, let support it.
Change-Id: I4bf302c395491ca49a1874c8984caa0b49cfb326
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
add both static and dynamic power coefficient for gpu
module, and add gpu as a cooling device in the thermal zone.
rename the thermal zone's config and make it more readable.
update temperature pooling interval and make the temperature
control more effective.
Change-Id: I6e0939fe26ece9c611151ffbbb55e62b824a602f
Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>
