| Age | Commit message (Collapse) | Author |
|---|
|
Currently, acpi.info is an invalid link to access ACPI specification,
the new valid link is https://uefi.org/specifications.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Use the newly introduced pm_ptr() macro to simplify the code.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
In previous patches that added support for new iowarrior devices, the
handling of the report size was not done correct.
Fix that up and update the copyright date for the driver
Reworked from an original patch written by Christoph Jung.
Fixes: bab5417f5f01 ("USB: misc: iowarrior: add support for the 100 device")
Fixes: 5f6f8da2d7b5 ("USB: misc: iowarrior: add support for the 28 and 28L devices")
Fixes: 461d8deb26a7 ("USB: misc: iowarrior: add support for 2 OEMed devices")
Cc: stable <stable@kernel.org>
Reported-by: Christoph Jung <jung@codemercs.com>
Link: https://lore.kernel.org/r/20200726094939.1268978-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next
Felipe writes:
USB: changes for v5.9 merge window
CDNS3 got several improvements, most of which are non-critical fixes.
DWC3 has a reset fix for the meson platform, while dwc2 has
improvements for role switch on STM32MP15 SoCs.
Apart from these, we have the usual set of non-critical fixes all over
the place and support for new Ingenic SoC to their PHY driver.
* tag 'usb-for-v5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb: (38 commits)
usb: dwc3: gadget: when the started list is empty stop the active xfer
usb: dwc3: gadget: make starting isoc transfers more robust
usb: dwc3: gadget: add frame number mask
usb: gadget: function: printer: Interface is disabled and returns error
usb: gadget: f_uac2: fix AC Interface Header Descriptor wTotalLength
dt-bindings: usb: ti,keystone-dwc3.yaml: Improve schema
usb: bdc: Use devm_clk_get_optional()
usb: bdc: Halt controller on suspend
usb: bdc: driver runs out of buffer descriptors on large ADB transfers
usb: bdc: Adb shows offline after resuming from S2
bdc: Fix bug causing crash after multiple disconnects
usb: bdc: Add compatible string for new style USB DT nodes
dt-bindings: usb: bdc: Update compatible strings
USB: PHY: JZ4770: Reformat the code to align it.
USB: PHY: JZ4770: Add support for new Ingenic SoCs.
USB: PHY: JZ4770: Unify code style and simplify code.
dt-bindings: USB: Add bindings for new Ingenic SoCs.
usb: gadget: net2280: fix memory leak on probe error handling paths
usb: cdns3: drd: simplify *switch_gadet and *switch_host
usb: cdns3: core: removed overwriting some error code
...
|
|
Having sync_core() in processor.h is problematic since it is not possible
to check for hardware capabilities via the *cpu_has() family of macros.
The latter needs the definitions in processor.h.
It also looks more intuitive to relocate the function to sync_core.h.
This changeset does not make changes in functionality.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Link: https://lore.kernel.org/r/20200727043132.15082-3-ricardo.neri-calderon@linux.intel.com
|
|
We want the driver core fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
Fold acpi_os_map_cleanup_deferred() into acpi_os_map_remove() and
pass the latter to INIT_RCU_WORK() in acpi_os_drop_map_ref() to make
the code more straightforward.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
There is no reason (knwon to me) why any of the existing users of
acpi_os_unmap_iomem() would need to wait for the unused memory
mappings left by it to actually go away, so use the deferred
unmapping of ACPI memory introduced previously in that function.
While at it, fold __acpi_os_unmap_iomem() back into
acpi_os_unmap_iomem(), which has become a simple wrapper around it,
and make acpi_os_unmap_memory() call the latter.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
There is no reason (knwon to me) why any of the existing users of
acpi_os_unmap_generic_address() would need to wait for the unused
memory mappings left by it to actually go away, so use the deferred
unmapping of ACPI memory introduced previously in that function.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The ACPICA's strategy with respect to the handling of memory mappings
associated with memory operation regions is to avoid mapping the
entire region at once which may be problematic at least in principle
(for example, it may lead to conflicts with overlapping mappings
having different attributes created by drivers). It may also be
wasteful, because memory opregions on some systems take up vast
chunks of address space while the fields in those regions actually
accessed by AML are sparsely distributed.
For this reason, a one-page "window" is mapped for a given opregion
on the first memory access through it and if that "window" does not
cover an address range accessed through that opregion subsequently,
it is unmapped and a new "window" is mapped to replace it. Next,
if the new "window" is not sufficient to acess memory through the
opregion in question in the future, it will be replaced with yet
another "window" and so on. That may lead to a suboptimal sequence
of memory mapping and unmapping operations, for example if two fields
in one opregion separated from each other by a sufficiently wide
chunk of unused address space are accessed in an alternating pattern.
The situation may still be suboptimal if the deferred unmapping
introduced previously is supported by the OS layer. For instance,
the alternating memory access pattern mentioned above may produce
a relatively long list of mappings to release with substantial
duplication among the entries in it, which could be avoided if
acpi_ex_system_memory_space_handler() did not release the mapping
used by it previously as soon as the current access was not covered
by it.
In order to improve that, modify acpi_ex_system_memory_space_handler()
to preserve all of the memory mappings created by it until the memory
regions associated with them go away.
Accordingly, update acpi_ev_system_memory_region_setup() to unmap all
memory associated with memory opregions that go away.
Reported-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Xiang Li <xiang.z.li@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The ACPI OS layer in Linux uses RCU to protect the walkers of the
list of ACPI memory mappings from seeing an inconsistent state
while it is being updated. Among other situations, that list can
be walked in (NMI and non-NMI) interrupt context, so using a
sleeping lock to protect it is not an option.
However, performance issues related to the RCU usage in there
appear, as described by Dan Williams:
"Recently a performance problem was reported for a process invoking
a non-trival ASL program. The method call in this case ends up
repetitively triggering a call path like:
acpi_ex_store
acpi_ex_store_object_to_node
acpi_ex_write_data_to_field
acpi_ex_insert_into_field
acpi_ex_write_with_update_rule
acpi_ex_field_datum_io
acpi_ex_access_region
acpi_ev_address_space_dispatch
acpi_ex_system_memory_space_handler
acpi_os_map_cleanup.part.14
_synchronize_rcu_expedited.constprop.89
schedule
The end result of frequent synchronize_rcu_expedited() invocation is
tiny sub-millisecond spurts of execution where the scheduler freely
migrates this apparently sleepy task. The overhead of frequent
scheduler invocation multiplies the execution time by a factor
of 2-3X."
The source of this is that acpi_ex_system_memory_space_handler()
unmaps the memory mapping currently cached by it at the access time
if that mapping doesn't cover the memory area being accessed.
Consequently, if there is a memory opregion with two fields
separated from each other by an unused chunk of address space that
is large enough for not being covered by a single mapping, and they
happen to be used in an alternating pattern, the unmapping will
occur on every acpi_ex_system_memory_space_handler() invocation for
that memory opregion and that will lead to significant overhead.
Moreover, acpi_ex_system_memory_space_handler() carries out the
memory unmapping with the namespace and interpreter mutexes held
which may lead to additional latency, because all of the tasks
wanting to acquire on of these mutexes need to wait for the
memory unmapping operation to complete.
To address that, rework acpi_os_unmap_memory() so that it does not
release the memory mapping covering the given address range right
away and instead make it queue up the mapping at hand for removal
via queue_rcu_work().
Reported-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Xiang Li <xiang.z.li@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This reverts commit 2d38dbf89a06d0f689daec9842c5d3295c49777f as it broke
the build in linux-next
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes: 2d38dbf89a06 ("test_firmware: Test platform fw loading on non-EFI systems")
Cc: stable@vger.kernel.org
Cc: Scott Branden <scott.branden@broadcom.com>
Cc: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20200727165539.0e8797ab@canb.auug.org.au
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This should resolve the merge/build issues reported when trying to
create linux-next.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Fix firwmare -> firmware.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
|
|
Remove unneeded blank line and align indentation with open parenthesis.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
Align indentation with open parenthesis (or fix existing alignment).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
Macros arguments should be enclosed by parenthesis for safety.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
Use proper kerneldoc to fix GCC warnings like:
drivers/memory/of_memory.c:30: warning: Function parameter or member 'dev' not described in 'of_get_min_tck'
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
Fix arbitary -> arbitrary.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
Remove some unneeded blank lines, align indentation with open
parenthesis (or fix existing alignment).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
Driver uses 'unsigned int' in other places instead of 'unsigned'.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
Macros arguments should be enclosed by parenthesis for safety.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
Use proper kerneldoc to fix GCC warnings like:
drivers/memory/omap-gpmc.c:299: warning: Function parameter or member 'cs' not described in 'gpmc_get_clk_period'
drivers/memory/omap-gpmc.c:432: warning: Excess function parameter 'ma' description in 'get_gpmc_timing_reg'
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
The line continuation contained spaces but still failed to properly
align with open parenthesis.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
Add missing braces to all arms of if statement to align with coding
convention.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
Add blank lines to improve code readability. No functional change.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
When the system is suspended, we can explicitly disable clock to save
power. To achieve this, we need save registers' state since it could be
lost after power off.
Implement power management which will:
- Turn the clock off after probing
- Disable clock and save registers' state on system suspend, as
well as enable clock and restore registers' state on resume
- Rely on the Power Domain framework to shutdown the intmux
power domain
Without CONFIG_PM, the clock is always on after probe stage.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
[maz: revamped commit message]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200727141734.24890-2-qiangqing.zhang@nxp.com
|
|
Booting the latest kernel with DEBUG_ATOMIC_SLEEP=y on a GICv4.1 enabled
box, I get the following kernel splat:
[ 0.053766] BUG: sleeping function called from invalid context at mm/slab.h:567
[ 0.053767] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 0, name: swapper/1
[ 0.053769] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.8.0-rc3+ #23
[ 0.053770] Call trace:
[ 0.053774] dump_backtrace+0x0/0x218
[ 0.053775] show_stack+0x2c/0x38
[ 0.053777] dump_stack+0xc4/0x10c
[ 0.053779] ___might_sleep+0xfc/0x140
[ 0.053780] __might_sleep+0x58/0x90
[ 0.053782] slab_pre_alloc_hook+0x7c/0x90
[ 0.053783] kmem_cache_alloc_trace+0x60/0x2f0
[ 0.053785] its_cpu_init+0x6f4/0xe40
[ 0.053786] gic_starting_cpu+0x24/0x38
[ 0.053788] cpuhp_invoke_callback+0xa0/0x710
[ 0.053789] notify_cpu_starting+0xcc/0xd8
[ 0.053790] secondary_start_kernel+0x148/0x200
# ./scripts/faddr2line vmlinux its_cpu_init+0x6f4/0xe40
its_cpu_init+0x6f4/0xe40:
allocate_vpe_l1_table at drivers/irqchip/irq-gic-v3-its.c:2818
(inlined by) its_cpu_init_lpis at drivers/irqchip/irq-gic-v3-its.c:3138
(inlined by) its_cpu_init at drivers/irqchip/irq-gic-v3-its.c:5166
It turned out that we're allocating memory using GFP_KERNEL (may sleep)
within the CPU hotplug notifier, which is indeed an atomic context. Bad
thing may happen if we're playing on a system with more than a single
CommonLPIAff group. Avoid it by turning this into an atomic allocation.
Fixes: 5e5168461c22 ("irqchip/gic-v4.1: VPE table (aka GICR_VPROPBASER) allocation")
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200630133746.816-1-yuzenghui@huawei.com
|
|
EXTI lines are mainly used to wake-up system from CStop low power mode.
Currently, if a device wants to use a EXTI (direct) line as wakeup line,
it has to declare 2 interrupts:
- one for EXTI used to wake-up system (with dedicated_wake_irq api).
- one for GIC used to get the wake up reason inside the concerned IP.
This split is not really needed as each EXTI line is actually "linked " to
a GIC. So to avoid this useless double interrupt management in each
wake-up driver, this patch lets the STM32 EXTI driver abstract it by
mapping each EXTI line to his corresponding GIC.
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200717140717.29606-1-alexandre.torgue@st.com
|
|
This driver can work as a platform driver. So covert it to a platform
driver.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Hanks Chen <hanks.chen@mediatek.com>
Link: https://lore.kernel.org/r/20200718000637.3632841-5-saravanak@google.com
|
|
This driver can work as a platform driver. So covert it to a platform
driver.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Hanks Chen <hanks.chen@mediatek.com>
Link: https://lore.kernel.org/r/20200718000637.3632841-4-saravanak@google.com
|
|
Switch the driver to use the helper macros. In addition to reducing the
number of lines, this also adds module unload protection (if the driver
is compiled as a module) by switching from module_platform_driver to
builtin_platform_driver.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200718000637.3632841-3-saravanak@google.com
|
|
Compiling an irqchip driver as a platform driver needs to bunch of
things to be done right:
- Making sure the parent domain is initialized first
- Making sure the device can't be unbound from sysfs
- Disallowing module unload if it's built as a module
- Finding the parent node
- Etc.
Instead of trying to make sure all future irqchip platform drivers get
this right, provide boilerplate macros that take care of all of this.
An example use would look something like this. Where acme_foo_init and
acme_bar_init are similar to what would be passed to IRQCHIP_DECLARE.
IRQCHIP_PLATFORM_DRIVER_BEGIN(acme_irq)
IRQCHIP_MATCH("acme,foo", acme_foo_init)
IRQCHIP_MATCH("acme,bar", acme_bar_init)
IRQCHIP_PLATFORM_DRIVER_END(acme_irq)
Signed-off-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: John Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/r/20200718000637.3632841-2-saravanak@google.com
|
|
The GICv4.1 spec tells us that it's CONSTRAINED UNPREDICTABLE to issue a
register-based invalidation operation for a vPEID not mapped to that RD,
or another RD within the same CommonLPIAff group.
To follow this rule, commit f3a059219bc7 ("irqchip/gic-v4.1: Ensure mutual
exclusion between vPE affinity change and RD access") tried to address the
race between the RD accesses and the vPE affinity change, but somehow
forgot to take GICR_INVALLR into account. Let's take the vpe_lock before
evaluating vpe->col_idx to fix it.
Fixes: f3a059219bc7 ("irqchip/gic-v4.1: Ensure mutual exclusion between vPE affinity change and RD access")
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200720092328.708-1-yuzenghui@huawei.com
|
|
cpu_logical_map is only defined for CONFIG_SMP builds, when we are in an
UP configuration, the boot CPU is 0.
Fixes: 6468fc18b006 ("irqchip/irq-bcm7038-l1: Add PM support")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200724184157.29150-1-f.fainelli@gmail.com
|
|
Allows qcom-pdc driver to be loaded as a permanent module
Also, due to the fact that IRQCHIP_DECLARE becomes a no-op when
building as a module, we have to replace it with platform driver
hooks explicitly.
Thanks to Saravana for his help on pointing out the
IRQCHIP_DECLARE issue and guidance on a solution.
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Maulik Shah <mkshah@codeaurora.org>
Cc: Lina Iyer <ilina@codeaurora.org>
Cc: Saravana Kannan <saravanak@google.com>
Cc: Todd Kjos <tkjos@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: iommu@lists.linux-foundation.org
Cc: linux-gpio@vger.kernel.org
Link: https://lore.kernel.org/r/20200710231824.60699-4-john.stultz@linaro.org
|
|
The sparse tool complains as follows:
drivers/irqchip/irq-mips-gic.c:49:1: warning:
symbol '__pcpu_scope_pcpu_masks' was not declared. Should it be static?
drivers/irqchip/irq-mips-gic.c:620:6: warning:
symbol 'gic_ipi_domain_free' was not declared. Should it be static?
drivers/irqchip/irq-mips-gic.c:634:5: warning:
symbol 'gic_ipi_domain_match' was not declared. Should it be static?
Those symbols are not used outside of irq-mips-gic.c, so marks
them static.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200714142245.16124-1-weiyongjun1@huawei.com
|
|
This is passed to irq_domain_add_linear(), which accepts a pointer
to a const structure.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200714173857.477422-1-masahiroy@kernel.org
|
|
Now that the hwspin_lock_timeout_in_atomic() API is available use it.
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200706081115.25180-1-alexandre.torgue@st.com
|
|
We want the USB fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://people.freedesktop.org/~agd5f/linux into drm-next
amd-drm-next-5.9-2020-07-24:
amdgpu:
- Misc sienna cichlid fixes
- Final bits of swSMU cleanup
- Misc display fixes
- Misc VCN fixes
- Eeprom i2c cleanup
- Drop amd vrr_range debugfs in favor of core drm
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200724205712.3913-1-alexander.deucher@amd.com
|
|
A couple of fixes for issues relating to format modifiers (there's
still a patch pending from James Jones to hopefully address the
remaining ones), regression fix from the recent HDA nightmare, and a
race fix for Turing modesetting.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Ben Skeggs <skeggsb@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ <CACAvsv5aAp+FZMZGTB+Nszc==h5gEbdNV58sSRRQDF1R5qQRGg@mail.gmail.com
|
|
Whenever a display update was sent, apart from updating
the memory base address, we called mcde_display_send_one_frame()
which also sent a command to the display requesting the TE IRQ
and enabling the FIFO.
When continuous updates are running this is wrong: we need
to only send this to start the flow to the display on
the very first update. This lead to the display pipeline
locking up and crashing.
Check if the flow is already running and in that case
do not call mcde_display_send_one_frame().
This fixes crashes on the Samsung GT-S7710 (Skomer).
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Stephan Gerhold <stephan@gerhold.net>
Cc: Stephan Gerhold <stephan@gerhold.net>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200718233323.3407670-1-linus.walleij@linaro.org
|
|
Refresh the branch for a dependent commit.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
We don't create a connector but let panel_bridge handle that so there's
no point in rejecting DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/8b6545b991afce6add0a24f5f5d116778b0cb763.1595096667.git.agx@sigxcpu.org
|
|
Fine tune the HBP and HFP to avoid the dot noise on the left and right edges.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200714123332.37609-1-jitao.shi@mediatek.com
|
|
On boe_nv133fhm_n62 (and presumably on boe_nv133fhm_n61) a scope shows
a small spike on the HPD line right when you power the panel on. The
picture looks something like this:
+--------------------------------------
|
|
|
Power ---+
+---
|
++ |
+----+| |
HPD -----+ +---------------------------+
So right when power is applied there's a little bump in HPD and then
there's small spike right before it goes low. The total time of the
little bump plus the spike was measured on one panel as being 8 ms
long. The total time for the HPD to go high on the same panel was
51.2 ms, though the datasheet only promises it is < 200 ms.
When asked about this glitch, BOE indicated that it was expected and
persisted until the TCON has been initialized.
If this was a real hotpluggable DP panel then this wouldn't matter a
whole lot. We'd debounce the HPD signal for a really long time and so
the little blip wouldn't hurt. However, this is not a hotpluggable DP
panel and the the debouncing logic isn't needed and just shows down
the time needed to get the display working. This is why the code in
panel_simple_prepare() doesn't do debouncing and just waits for HPD to
go high once. Unfortunately if we get unlucky and happen to poll the
HPD line right at the spike we can try talking to the panel before
it's ready.
Let's handle this situation by putting in a 15 ms prepare delay and
decreasing the "hpd absent delay" by 15 ms. That means:
* If you don't have HPD hooked up at all you've still got the
hardcoded 200 ms delay.
* If you've got HPD hooked up you will always wait at least 15 ms
before checking HPD. The only case where this could be bad is if
the panel is sharing a voltage rail with something else in the
system and was already turned on long before the panel came up. In
such a case we'll be delaying 15 ms for no reason, but it's not a
huge delay and I don't see any other good solution to handle that
case.
Even though the delay was measured as 8 ms, 15 ms was chosen to give a
bit of margin.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716132120.1.I01e738cd469b61fc9b28b3ef1c6541a4f48b11bf@changeid
|
|
After the drm_bridge_connector_init() helper function has been added,
the ADV driver has been changed accordingly. However, the 'type'
field of the bridge structure was left unset, which makes the helper
function always return -EINVAL.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Tested-by: Vinod Koul <vkoul@kernel.org> # tested on DragonBoard 410c
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200720124228.12552-1-laurentiu.palcu@oss.nxp.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc into master
Pull char/misc driver fixes from Greg KH:
"Here are a few small driver fixes for 5.8-rc7
They include:
- habanalabs fixes
- tiny fpga driver fixes
- /dev/mem fixup from previous changes
- interconnect driver fixes
- binder fix
All of these have been in linux-next for a while with no reported
issues"
* tag 'char-misc-5.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
interconnect: msm8916: Fix buswidth of pcnoc_s nodes
interconnect: Do not skip aggregation for disabled paths
/dev/mem: Add missing memory barriers for devmem_inode
binder: Don't use mmput() from shrinker function.
habanalabs: prevent possible out-of-bounds array access
fpga: dfl: fix bug in port reset handshake
fpga: dfl: pci: reduce the scope of variable 'ret'
habanalabs: set 4s timeout for message to device CPU
habanalabs: set clock gating per engine
habanalabs: block WREG_BULK packet on PDMA
|
