Now that all conversions are done, move the FibreChannel bsg code over
to the bsg library.
This patch is derived from work done by Mike Christie in 2011 [1] but
only the iscsi parts got merged back then.
[1] http://marc.info/?l=linux-scsi&m=131149780921009&w=2
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add bsg_job_put() and bsg_job_get() so don't need to export
bsg_destroy_job() any more.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
fc_bsg_jobdone() and bsg_job_done() are 1:1 copies now so use the
bsg-lib one instead of the FC private implementation.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
bsg_softirq_done() and fc_bsg_softirq_done() are copies of each other, so
ditch the fc specific one.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
fc_destroy_bsgjob() and bsg_destroy_job() are now 1:1 copies, so use the
latter. As bsg_destroy_job() comes from bsg-lib we need to select it in
Kconfig once CONFOG_SCSI_FC_ATTRS is active.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Change FC drivers to use 'struct bsg_job' from bsg-lib.h instead of
'struct fc_bsg_job' from scsi_transport_fc.h and remove 'struct
fc_bsg_job'.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add reference counting to 'struct bsg_job' so we can implement a reuqest
timeout handler for bsg_jobs, which is needed for Fibre Channel.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Implement kref backed reference counting instead of rolling our own. This
elimnates the need of the following fields in 'struct fc_bsg_job':
* ref_cnt
* state_flags
* job_lock
bringing us close to unification of 'struct fc_bsg_job' and 'struct bsg_job'.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Don't set FC_RQST_STATE_DONE before calling fc_bsg_jobdone() as
fc_bsg_jobdone() calls blk_complete_requeust() which raises a soft-IRQ
that ends up in fc_bsg_sofirq_done() and fc_bsg_softirq_done() sets the
FC_RQST_STATE_DONE flag.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Provide fc_bsg_to_rport() helper that will become handy when we're
moving from struct fc_bsg_job to a plain struct bsg_job. Also move all
LLDDs to use the new helper.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Provide fc_bsg_to_shost() helper that will become handy when we're
moving from struct fc_bsg_job to a plain struct bsg_job. Also use this
little helper in the LLDDs.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Export fc_bsg_jobdone so drivers can use it directly instead of doing
the round-trip via struct fc_bsg_job::job_done() and use it in the
LLDDs. That way we can also unify the interfaces of fc_bsg_jobdone and
bsg_job_done.
As we've converted all LLDDs over to use fc_bsg_jobdone() directly, we
can remove the function pointer from struct fc_bsg_job as well.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Don't use fc_bsg_job::request and fc_bsg_job::reply directly, but use
helper variables bsg_request and bsg_reply. This will be helpful when
transitioning to bsg-lib.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
struct fc_bsg_buffer is just a clone of struct bsg_buffer from bsg-lib,
so use this one instead.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Documentation/CodingStyle recommends to use label names which say
what the goto does or why the goto exists.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Allow more flexibility to bus speed selection. Now if there are I2C
slave connections defined in ACPI the speed of slowest device on the bus
will define the bus speed. However if also "clock-frequency" device
property is defined we should use the slowest of these two.
This is targeted to maker boards where developer may want to connect
slower I2C slave devices to the bus than defined in existing ACPI I2C
slave connections.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Free and Open IPMI use SMBUS BLOCK Read/Write to support SSIF protocol.
However, I2C Designware Core Driver doesn't handle the case at the moment.
The below patch supports this feature.
Signed-off-by: Tin Huynh <tnhuynh@apm.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Check for i2c_adapter_quirks structures that are only stored in the
quirks field of an i2c_adapter structure. This field is declared
const, so i2c_adapter_quirks structures that have this property can be
declared as const also.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Ray Jui <ray.jui@broadcom.com> # for bcm-iproc
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Linux 4.8 added support for runtime suspending PCIe ports to D3hot with
commit 006d44e49a ("PCI: Add runtime PM support for PCIe ports"), but
excluded hotplug ports. Those are now afforded runtime PM by the present
commit.
Hotplug ports require a few extra considerations:
- The configuration space of the port remains accessible in D3hot, so all
the functions to read or modify the Slot Status and Slot Control
registers need not be modified. Even turning on slot power doesn't seem
to require the port to be in D0, at least the PCIe spec doesn't say so
and I confirmed that by testing with a Thunderbolt controller.
- However D0 is required to access devices on the secondary bus. This
happens in pciehp_check_link_status() and pciehp_configure_device() (both
called from board_added()) and in pciehp_unconfigure_device() (called
from remove_board()), so acquire a runtime PM ref for their invocation.
- The hotplug port stays active as long as it has active children. If all
hotplugged devices below the port runtime suspend, the port is allowed to
runtime suspend as well. Plug and unplug detection continues to work in
D3hot.
- Hotplug interrupts are delivered in-band, so while the hotplug port
itself is allowed to go to D3hot, its parent ports must stay in D0 for
interrupts to come through. Add a corresponding restriction to
pci_dev_check_d3cold().
- Runtime PM may only be allowed if the hotplug port is handled natively by
the OS. On ACPI systems, the port may alternatively be handled by the
firmware and things break if the OS puts the port into D3 behind the
firmware's back: E.g. Thunderbolt hotplug ports on non-Macs are handled
by Intel's firmware in System Management Mode and the firmware is known
to access devices on the port's secondary bus without checking first if
the port is in D0: https://bugzilla.kernel.org/show_bug.cgi?id=53811
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: Mika Westerberg <mika.westerberg@linux.intel.com>
since clk_prepare_enable() is used to get i2c->clk, we should
use clk_disable_unprepare() to release it for the error path.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
We're about to add runtime PM of hotplug ports, but we need to restrict it
to ports that are handled natively by the OS: If they're handled by the
firmware (which is the case for Thunderbolt on non-Macs), things would
break if the OS put the ports into D3hot behind the firmware's back.
To determine if a hotplug port is handled natively, one has to walk up from
the port to the root bridge and check the cached _OSC Control Field for the
value of the "PCI Express Native Hot Plug control" bit. There's already a
function to do that, device_is_managed_by_native_pciehp(), but it's private
to drivers/pci/hotplug/acpiphp_glue.c and only compiled in if
CONFIG_HOTPLUG_PCI_ACPI is enabled.
Make it public and move it to drivers/pci/pci-acpi.c, so that it is
available in the more general CONFIG_ACPI case.
The function contains a check if the device in question is a hotplug port
and returns false if it's not. The caller we're going to add doesn't need
this as it only calls the function if it actually *is* a hotplug port.
Move the check out of the function into the single existing caller.
Rename it to pciehp_is_native() and add some kerneldoc and polish.
No functional change intended.
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We cache the PCI_EXP_SLTCAP_HPC bit in pci_dev->is_hotplug_bridge on device
probe, so there's no need to read it again when adding the ACPI hotplug
context.
Here's the call chain to prove that no ordering issue is introduced:
pci_scan_child_bus [drivers/pci/probe.c]
pci_scan_slot
pci_scan_single_device
pci_scan_device
pci_setup_device
set_pcie_hotplug_bridge
[is_hotplug_bridge bit is set here]
pci_scan_bridge
pci_add_new_bus
pci_alloc_child_bus
pcibios_add_bus [arch/(x86|arm64|ia64)/...]
acpi_pci_add_bus [drivers/pci/pci-acpi.c]
acpiphp_enumerate_slots [drivers/pci/hotplug/acpiphp_glue.c]
acpiphp_add_context
device_is_managed_by_native_pciehp
[is_hotplug_bridge bit is queried here]
No functional change intended.
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The conditions to block D3 on parent ports are currently condensed into a
single expression in pci_dev_check_d3cold(). Upcoming commits will add
further conditions for hotplug ports, making this expression fairly large
and impenetrable. Unfold the conditions to maintain readability when they
are amended.
No functional change intended.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Mika Westerberg <mika.westerberg@linux.intel.com>
CC: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The conditions to allow runtime PM on PCIe ports are currently spread
across two different files: The condition relating to hotplug ports is
located in portdrv_pci.c whereas all other conditions are located in pci.c.
Consolidate all conditions in a single place in pci.c, thus making it
easier to follow the logic and amend conditions down the road.
Note that the condition relating to hotplug ports is inserted *before* the
condition relating to the "pcie_port_pm=force" command line option, so
runtime PM is not afforded to hotplug ports even if this option is given.
That's exactly how the code behaved up until now. If this is not desired,
the ordering of the conditions can simply be reversed.
No functional change intended.
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Currently pcie_portdrv_probe() activates runtime PM on a PCIe port even
if it will never actually suspend because the BIOS is too old or the
"pcie_port_pm=off" option was specified on the kernel command line.
A few CPU cycles can be saved by not activating runtime PM at all in these
cases, because rpm_idle() and rpm_suspend() will bail out right at the
beginning when calling rpm_check_suspend_allowed(), instead of carrying out
various locking and assignments, invoking rpm_callback(), getting back
-EBUSY and rolling everything back.
The conditions checked in pci_bridge_d3_possible() are all static, they
never change during uptime of the system, hence it's safe to call this to
determine if runtime PM should be activated.
No functional change intended.
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After a device has been added, removed or had its D3cold attributes
changed, we recheck whether its parent bridge may runtime suspend to D3hot
with pci_bridge_d3_update().
The most naive algorithm would be to iterate over the bridge's children and
check if any of them are blocking D3.
The function already tries to be a bit smarter than that by first checking
the device that was changed. If this device already blocks D3 on the
bridge, then walking over all the other children can be skipped. A
drawback of this approach is that if the device is *not* blocking D3, it
will be checked a second time by pci_walk_bus(). But that's cheap and is
outweighed by the performance gain of potentially skipping pci_walk_bus()
altogether.
The algorithm can be optimized further by taking into account if D3 is
currently allowed for the bridge, as shown in the following truth table:
(a) remove && bridge_d3: D3 is currently allowed for the bridge and
removing one of its children won't change
that. No action necessary.
(b) remove && !bridge_d3: D3 may now be allowed for the bridge if the
removed child was the only one blocking it.
Check all its siblings to verify that.
(c) !remove && bridge_d3: D3 may now be disallowed but this can only
be caused by the added/changed child, not
any of its siblings. Check only that single
device.
(d) !remove && !bridge_d3: D3 may now be allowed for the bridge if the
changed child was the only one blocking it.
Check all its siblings to verify that.
By checking beforehand if the changed child
is blocking D3, we may be able to skip
checking its siblings.
Currently we do not special-case option (a) and in case of option (c) we
gratuitously call pci_walk_bus(). Speed up the algorithm by adding these
optimizations. Reword the comments a bit in an attempt to improve clarity.
No functional change intended.
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The algorithm to update the flag indicating whether a bridge may go to D3
makes a few optimizations based on whether the update was caused by the
removal of a device on the one hand, versus the addition of a device or the
change of its D3cold flags on the other hand.
The information whether the update pertains to a removal is currently
passed in by the caller, but the function may as well determine that itself
by examining the device in question, thereby allowing for a considerable
simplification and reduction of the code.
Out of several options to determine removal, I've chosen the function
device_is_registered() because it's cheap: It merely returns the
dev->kobj.state_in_sysfs flag. That flag is set through device_add() when
the root bus is scanned and cleared through device_remove(). The call to
pci_bridge_d3_update() happens after each of these calls, respectively, so
the ordering is correct.
No functional change intended.
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The Kconfig currently controlling compilation of this code is:
drivers/i2c/busses/Kconfig:config I2C_PXA_PCI
drivers/i2c/busses/Kconfig: def_bool I2C_PXA && X86_32 && PCI && OF
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.
Since module_pci_driver() uses the same init level priority as
builtin_pci_driver() the init ordering remains unchanged with
this commit.
Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
We also delete the MODULE_LICENSE tag etc. since all that information
was (or is now) contained at the top of the file in the comments.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
This function is always called with an existing pci_dev struct, which
holds a reference on the pci_bus struct it resides on, which in turn
holds a reference on pci_bus->bridge, which is the pci_dev's parent.
Hence there's no need to acquire an additional ref on the parent.
More specifically, the pci_dev exists until pci_destroy_dev() drops the
final reference on it, so all calls to pci_bridge_d3_update() must be
finished before that. It is arguably the caller's responsibility to ensure
that it doesn't call pci_bridge_d3_update() with a pci_dev that might
suddenly disappear, but in any case the existing callers are all safe:
- The call in pci_destroy_dev() happens before the call to put_device().
- The call in pci_bus_add_device() is synchronized with pci_destroy_dev()
using pci_lock_rescan_remove().
- The calls to pci_d3cold_disable() from the xhci and nouveau drivers
are safe because a ref on the pci_dev is held as long as it's bound to
a driver.
- The calls to pci_d3cold_enable() / pci_d3cold_disable() when modifying
the sysfs "d3cold_allowed" entry are also safe because kernfs_drain()
waits for existing sysfs users to finish before removing the entry,
and pci_destroy_dev() is called way after that.
No functional change intended.
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
A fix to reintroduce missing pinmux options that turned out not to be
optional.
-----BEGIN PGP SIGNATURE-----
iQIcBAABCAAGBQJYK3mGAAoJEBx+YmzsjxAg2nEQAK/mc4R4yram78qXD5B+tbji
o04PuC2xvST0xI7N4fnNxueZQOYoqKEvbUlGa32kQ4Zs20qCrnRntlfjjNvs+UQc
O9EOTJnH1T+sABY+LOq3rcoK8zswl7ka+dsQ3STaL+OFVfox+Bw2IjCZ1KBOLjgU
4joOeuOTrmSTS5i6IxvGPmGZBb5hbq9TaYsQyIKUozaLjDGgDgZ1GKjJhN9LdjM5
n7K8Bf87YQhuxKgQv2H3rxseooe95IVmfc8zv+CnLSrC63oJwpiAemVuaPKOq7dt
gTxkYIBBtHMwY/OHpXRI0FNxuhaPUn8Nxo9QxTij9aH44lfZr2RS/0f/KHIe2KrM
Nh8mUMTotgSfdmD5OrShgJV28B6MxzJMhUisi+GGglR0N4GNeXZ5dtNOgY35Rmjw
geJNPjnL7ALkXcrLPxGyPttcw8p/wtSgDnbOINWZ0aJ7NfTgqCsi4uYkOJSm4NII
unthkLr/y5uwWMkPNoGtoqGOF0kMTcXy5gf/S45mdKzU2c8dKi6POph7kVeVxC1F
OBIQ+s2H0E4D6rOz9g7R7lwO/tFVltXz1lhvQ+CebM5/NH1vjVuKDe0+SrvDfQBm
6IYzepW3tVjJTWJr09xUfzwtkm5ii6lEvChllnmrInhpgDCnKv9qDgbnJCnLlUYs
D7JrBkNV+976JqdOlX5l
=WBs5
-----END PGP SIGNATURE-----
Merge tag 'sunxi-fixes-for-4.9' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into fixes
Allwinner fixes for 4.9
A fix to reintroduce missing pinmux options that turned out not to be
optional.
* tag 'sunxi-fixes-for-4.9' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
ARM: dts: sun8i: fix the pinmux for UART1
Signed-off-by: Olof Johansson <olof@lixom.net>
It fixes a boot failure on imx53-qsb board with a DA9053 PMIC, which is
caused by the regulator core change, commit fa93fd4ecc ("regulator:
core: Ensure we are at least in bounds for our constraints").
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJYKnQ1AAoJEFBXWFqHsHzOyEYH/0F1TKtmJwLeDBKBinmeG0wx
IX/0mXCV0E72T7W6PuifofG7H9jax9UY8qGyDl9+h/dMBQCaKPfXDo6wg5FoXaBe
UAQVHbRbEuazI2xW0UWeiywt6soGBe1/iNpt+OXXfmJY77vS5nuGfFCLGey6+uTe
WeGi3J6g2Oxa65FndvfTm5dNj6vCa3VHs5UKQKCId3KoTjuLZu4EUrN81e47tkmJ
pmzaGBfAUyvACfwkITzc6rAbBp29FtxMK52ieuh+w4L3DWa3kpCabHPMIAeP8C9P
GQ80PTyfs/F163yYM6dWRipwhz/XJhjtT8SWBG/hnYBJDEHOua4uqW3YcoNdm7E=
=xunY
-----END PGP SIGNATURE-----
Merge tag 'imx-fixes-4.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes
i.MX fixes for 4.9, 2nd round:
It fixes a boot failure on imx53-qsb board with a DA9053 PMIC, which is
caused by the regulator core change, commit fa93fd4ecc ("regulator:
core: Ensure we are at least in bounds for our constraints").
* tag 'imx-fixes-4.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: dts: imx53-qsb: Fix regulator constraints
Signed-off-by: Olof Johansson <olof@lixom.net>
features printed, all these are quite trivial and tiny. The omap5 jack
detection and gpadc patches are not strictly fixes, but I wanted to get
binding document typo fixed before it pops up on other boards. The
gpadc one liner was in the same series and I applied and pushed it out
already before noticing it could have waited. The list of changes is:
- Fix omap3 SoC features printed
- Make sure OMAP_INTERCONNECT is selected for am43xx only configurations
- Add missing memory node for torpedo
- Initialize uart4_mask properly to avoid writing garbage to PRM registers
- Fix NULL pointer dereference for omap4 volt_data
- Add alias for omap5 gpadc needed by iio drivers
- Enable omap5 jack headset jack detection and fix it's binding typo
- Add missing memory node for logicpd-som-lv
- Fix wrong SMPS6 voltage for VDD-DDR3 for omap5
-----BEGIN PGP SIGNATURE-----
iQIuBAABCAAYBQJYKlYvERx0b255QGF0b21pZGUuY29tAAoJEBvUPslcq6VzT50Q
AJEsYX1dYwMyVeditzSWb65ajT53uhxPw51vIfA/bV3FUsMTaD5aZ9fsxYMt/3Eo
ayEzDFM74FM9nMGB4gXW4wryta4r5NT/lBg6vvwJfivVjTUkhQUKmH6C94dg3t2d
bHr9isM7ONJ5wxx02olg9vHyNXXgWEwPLhWKtxZKanKpoxKJajSA5dJuZR9T39X5
ZuhPFFmpMEh+IsnqYs4C1+215cFkRf21aEhMqwKRySTcHf35zitPfiuYF4Gft6Vb
Cor9JXlZGUN+dfhG48qcn+1NBEgha5r7JT2u7w+dPCXKvEn6OmpyAziUT3CYHMAc
IGeZLmBznhSZhJUvYjBmiy88YLORpWvPuGCE19AKJoi+VOGv8bSc2bnp+JCw+Ven
DB0GDWJgI2FVPNrRrLRW+dOdKwH/R8b9vE3ZtVHK8x7vowViDoGyFpndv30sL0HA
ssRvC24wAyRAcpXtAqQrFc2I8BMLzVsLzHLHriR9EnhMAspk4IJV5zkFv52ZtlxO
N6NabaD7se2ww7q3MSGuIe3+u9u3KcfKf1dsaq/E8cWFxvcJ07xnCCCYJ8DlGmZh
mS+Fkbof7NO0gbSiapzgjVtb+sfrkKqYTiIMldTzIGzmEcpK6SKXC6mAcrFAPojK
ecBq9BrLuAte4u6W1ohQoAW6rwjfz6yrAqIdzhzufGsN
=LgIW
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v4.9/fixes-for-rc-cycle' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
Fixes for omaps for v4.9-rc cycle. Except for the omap3 fix for the SoC
features printed, all these are quite trivial and tiny. The omap5 jack
detection and gpadc patches are not strictly fixes, but I wanted to get
binding document typo fixed before it pops up on other boards. The
gpadc one liner was in the same series and I applied and pushed it out
already before noticing it could have waited. The list of changes is:
- Fix omap3 SoC features printed
- Make sure OMAP_INTERCONNECT is selected for am43xx only configurations
- Add missing memory node for torpedo
- Initialize uart4_mask properly to avoid writing garbage to PRM registers
- Fix NULL pointer dereference for omap4 volt_data
- Add alias for omap5 gpadc needed by iio drivers
- Enable omap5 jack headset jack detection and fix it's binding typo
- Add missing memory node for logicpd-som-lv
- Fix wrong SMPS6 voltage for VDD-DDR3 for omap5
* tag 'omap-for-v4.9/fixes-for-rc-cycle' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: omap5: board-common: fix wrong SMPS6 (VDD-DDR3) voltage
ARM: omap3: Add missing memory node in SOM-LV
ASoC: omap-abe-twl6040: fix typo in bindings documentation
dts: omap5: board-common: enable twl6040 headset jack detection
dts: omap5: board-common: add phandle to reference Palmas gpadc
ARM: OMAP2+: avoid NULL pointer dereference
ARM: OMAP2+: PRM: initialize en_uart4_mask and grpsel_uart4_mask
ARM: dts: omap3: Fix memory node in Torpedo board
ARM: AM43XX: Select OMAP_INTERCONNECT in Kconfig
ARM: OMAP3: Fix formatting of features printed
Signed-off-by: Olof Johansson <olof@lixom.net>
All of them are fixes for arm64 device tree
- 2 for the SPI node on the Armada 7K/8K
- 1 for the clock node on the Armada 37xx
-----BEGIN PGP SIGNATURE-----
iGoEABECACoFAlgk6sUjHGdyZWdvcnkuY2xlbWVudEBmcmVlLWVsZWN0cm9ucy5j
b20ACgkQCwYYjhRyO9VwEgCdGuixX9TYgWna2/PdhtVs5JXdW98Amwb054ygu7dw
2ONd6XGynL1PpVhQ
=qm28
-----END PGP SIGNATURE-----
Merge tag 'mvebu-fixes-4.9-1' of git://git.infradead.org/linux-mvebu into fixes
mvebu fixes for 4.9 (part 1)
All of them are fixes for arm64 device tree
- 2 for the SPI node on the Armada 7K/8K
- 1 for the clock node on the Armada 37xx
* tag 'mvebu-fixes-4.9-1' of git://git.infradead.org/linux-mvebu:
arm64: dts: marvell: add unique identifiers for Armada A8k SPI controllers
arm64: dts: marvell: fix clocksource for CP110 slave SPI0
arm64: dts: marvell: Fix typo in label name on Armada 37xx
Signed-off-by: Olof Johansson <olof@lixom.net>
i915 misc fixes.
* tag 'drm-intel-fixes-2016-11-17' of ssh://git.freedesktop.org/git/drm-intel:
drm/i915: Assume non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT
drm/i915: Refresh that status of MST capable connectors in ->detect()
drm/i915: Grab the rotation from the passed plane state for VLV sprites
drm/i915: Mark CPU cache as dirty when used for rendering
The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the
other is H8S/2168 compliant.
The current ipmi/bt-bmc driver implements the IPMI version and we
should reflect its nature in the compatible node name using
'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The
latter should be used for a H8S interface driver if it is implemented
one day.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Trivial fix to spelling mistake "configutation" to "configuration"
in dev_err message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
cec_read() is non-atomic in the presence of other I2C bus transactions
to the same device. This presents a problem when we add support for
the TDA9950 CEC engine part - both drivers can be trying to access the
device.
Avoid the inherent problems by switching to i2c_transfer() instead,
which allows us to perform more than one bus transaction atomically.
As this means we will be using I2C transactions rather than SMBUS, we
have to check that the host supports I2C functionality.
Tested-by: Brian Starkey <brian.starkey@arm.com>
Reviewed-by: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Some TDA998x contain several different I2C devices - there is the HDMI
encoder, and there is a TDA9950 CEC engine. These two share the same
interrupt signal.
In order to allow a driver for the CEC engine to work, we need to be
able to share the interrupt with the CEC driver, so convert the handler
and registration to allow this to happen.
Tested-by: Brian Starkey <brian.starkey@arm.com>
Reviewed-by: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Disabling the pre-filter block of the TDA998x saves 40mW and the colour
conversion block saves 15mW. As we always disable these two blocks, we
can power these sections of the chip down to save 55mW of unnecessary
power consumption.
Tested-by: Brian Starkey <brian.starkey@arm.com>
Reviewed-by: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Rather than storing the DPMS mode (which will always be on or off) use a
boolean to store this instead.
Tested-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
tda998x_audio_get_eld() is needlessly complex - the connector associated
with the encoder is always our own priv->connector. Remove this
complexity, but ensure that there are no races when copying out the ELD.
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Group the TDA998x audio functions together rather than split between
two different locations in the file, keeping like code together.
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Separate out the connector initialisation from the rest of the drivers
initialisation.
Tested-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Group the TDA998x connector functions and funcs structures together
before the encoder support, rather than scattered amongst the rest of
the file. This keeps like code together.
Tested-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
The naming of tda998x_encoder_set_config() is a left-over from when
TDA998x was a slave encoder. Since this is part of the initialisation,
drop the _encoder from the name, and move it near tda998x_bind().
Tested-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Correct two references to tda998x_connector_get_modes() which were
incorrectly referring to tda998x_encoder_get_modes().
Tested-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Check for audio support by the attached sink by consulting the EDID
prior to enabling audio over the TMDS link. We must consult the EDID
after calling drm_helper_probe_single_connector_modes(), as this can
use an override EDID, or load a replacement EDID.
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
