Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On 21/11/14 18:14, Mark Brown wrote: On Fri, Nov 21, 2014 at 02:35:07PM +0200, Jyri Sarha wrote: On 11/21/2014 01:23 PM, Mark Brown wrote: With this specific series I also need to figure out what all the video side is about (like I said earlier a lot of the patches look like they're supposed to be simple fixes for the video code not terribly closely tied to the rest of the series but none of them are getting applied) and what the end goal is beyond mechanically moving code. The end goal of this series is to fix OMAP HDMI audio, that got broken couple of releases ago. At the same time I cleaned up the old complex scheme to make the connection between the video and audio parts and allow multiple HDMI devices (DSS side is not ready for this yet, but audio side is). But in what way is it broken and how did this happen? Why are none of I don't have a clear answer, but it probably involves lack of use, and buggy and hard to use implementation. Things have changed around the original HDMI audio implementation, and it stopped working at some point. As the original implementation was found rather lacking, and with some fundamental issues, it was deemed better to have a fresh approach. the patches which look like they're supposed to be bug fixes early on in the series getting applied? I had thought this was just a lack of interest on the video side but it seems there's some other problems since the series has apparently been discussed off-list and still it's just as big as it was initially. The whole series is about HDMI audio, not video. The main HDMI driver resides in the fbdev directory, as the video side is the master here, and it contains the code to access the registers (including audio related registers). The sound/ part in this series acts as a logic between the asoc and the low level HDMI driver. This series only touch the parts about HDMI audio, so the fixes early on don't really fix anything without the rest of the series (as the current HDMI audio doesn't work). And in any case, I don't like applying individual patches from a series. Usually that just complicates things. If I would apply some of the early patches to fbdev, then this series would no longer work on plain mainline kernel, and would instead depend on fbdev tree. The situation would be ever worse if you'd also pick some of the audio patches to sound tree, creating a dependency to two subsystem trees. So if there's no particular important reason to pick patches from a series, I rather keep it as a whole to simplify merging and testing. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
2014-11-21 23:25 GMT+01:00 Griffis, Brad bgrif...@ti.com: -Original Message- From: Richard Cochran [mailto:richardcoch...@gmail.com] On Fri, Nov 21, 2014 at 07:17:18PM +0100, Johannes Pointner wrote: Before the patches were also jumps but I thought it is something Vignesh should know. Maybe there is some fix for that too? I believe I've seen the jumping behavior pop up at a couple random times in my testing. I think it relates to the hardware not properly registering a pen-up interrupt. When that's happening can you try running ts_calibrate? If you're not registering a pen-up event then you won't be able to advance through those touch points. Is this behavior related to capturing ADC samples, or do you see this behavior even without capturing ADC samples? Is it the right way to test? Because I think the ts_lib will cover misbehavior of the touchscreen driver. As Richard also noted, it would be nice if ti could let us know how to get the delay values right. By trial and error is IMHO not the best way. That is not only an opinion, it is a matter of fact. TI really dropped the ball on this one. I thought the patch series was a sign they finally were going to properly address this issue. Wrong again. These patches originate from work I did on TI's SDK 7.00 (3.12 kernel). The touchscreen is working beautifully in that environment and we are putting forth significant effort to bring those improvements to the community. Things do not seem to be working as well with the current mainline kernel. I've been reviewing various patches between 3.12 and the mainline to understand why it's different. I believe I have figured this out, and I have discussions going separately with individuals that contributed those patches in order to come up with the best possible solution, i.e. we likely need a few additional changes to this patch set. Ok, then I'm looking forward for a new patch set to test. Furthermore, I would be interested which changes you are talking about. The CHARGECONFIG delay serves precisely the same purpose as the udelay in the original code base. How did you determine the udelay value in the first place? I went through the effort of figuring out a way to make the delay into a HARDWARE delay instead of a software delay so that it could be removed from the ISR. That delay time relates to settling time and so it's going to be dependent on your PCB. You could hook up an oscilloscope and attempt to capture this parameter from the signals themselves. Personally I think that's a lot more difficult than just doing a few iterations of testing. I did measure with an oscilloscope to get the right charge delay and it looks fine to me. But I can't affect the jumps with the charge delay, the only thing that helped, was to add some sample delay. But it didn't solve it. The data sheet for the TI part used to have a reference to an app-note for the touch controller. spruh73f page 1154 The Pen IRQ can only occur if the correct Pen Ctrl bits are high (AFE Pen Ctrl bits 6:5 in the TSC_ADC control register) and if the correct ground transistor biasing is set in the StepConfig [N] Register. Refer to the application notes for the correct settings. I searched high and low for this application note. Then, the data sheet got revised. Such an application note does not exist, which explains why you didn't find it and why we have removed that reference from the TRM. Sorry for your trouble. We always strive for accurate documentation. Thanks, Hannes -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On 21/11/14 18:38, Mark Brown wrote: On Fri, Nov 21, 2014 at 02:10:11PM +0200, Jyri Sarha wrote: OMAP HDMI audio is fundamentally different to the case on Armada or on BBB. In omap the whole HDMI IP is integrated to the SoC and there really is no codec in the ASoC sense. The the cpu-dai transmits the audio directly to hdmi wire and there is no i2s bus involved. So this case should not be mixed with the patches Jean-Francois working on. The code is also orthogonal in that sense that the latest omap-hdmi-audio uses the generic dymmy codec. The discussion seemed to be about what to do with unplugged connections which isn't what you're talking about there and does seem like an area where we should at least be aiming for common behaviour even if not a common implementation. There's also all the stuff about parsing EDIDs for capabilities which would seem to be related to that but seems to have gone off into the weeds. I agree all these should be studied and worked further. However, I would still like to merge this series in the next merge window: a) The series does fix the OMAP HDMI audio, so that users can actually use it. b) The series does make the driver model much better, so that I can actually be bothered to keep it enabled (earlier, even when it more or less worked, it was too much hassle when doing development using modules). Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
On 11/21/2014 02:10 PM, Richard Cochran wrote: On the BB white using the LCD4 cape and the shipped debian kernel, the cursor *does* jump away, but not as often or as far as on the custom design I was working with. This sounds like the ADC is still sampling while the input data becomes invalid. Usually there is a resistor on the wiper line and the touchscreen manual says how much it should be at least. Could you please check if this is properly installed? Thanks, Richard Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] mailbox/omap: adapt to the new mailbox framework
On 4 November 2014 at 04:35, Suman Anna s-a...@ti.com wrote:
The OMAP mailbox driver and its existing clients (remoteproc
for OMAP4+) are adapted to use the generic mailbox framework.
The main changes for the adaptation are:
- The tasklet used for Tx is replaced with the state machine from
the generic mailbox framework. The workqueue used for processing
the received messages stays intact for minimizing the effects on
the OMAP mailbox clients.
- The existing exported client API, omap_mbox_get, omap_mbox_put and
omap_mbox_send_msg are deleted, as the framework provides equivalent
functionality. A OMAP-specific omap_mbox_request_channel is added
though to support non-DT way of requesting mailboxes.
- The OMAP mailbox driver is integrated with the mailbox framework
through the proper implementations of mbox_chan_ops, except for
.last_tx_done and .peek_data. The OMAP mailbox driver does not need
these ops, as it is completely interrupt driven.
- The OMAP mailbox driver uses a custom of_xlate controller ops that
allows phandles for the pargs specifier instead of indexing to avoid
any channel registration order dependencies.
- The new framework does not support multiple clients operating on a
single channel, so the reference counting logic is simplified.
- The remoteproc driver (current client) is adapted to use the new API.
The notifier callbacks used within this client is replaced with the
regular callbacks from the newer framework.
- The exported OMAP mailbox API are limited to omap_mbox_save_ctx,
omap_mbox_restore_ctx, omap_mbox_enable_irq omap_mbox_disable_irq,
with the signature modified to take in the new mbox_chan handle instead
of the OMAP specific omap_mbox handle. The first 2 will be removed when
the OMAP mailbox driver is adapted to runtime_pm. The other exported
API omap_mbox_request_channel will be removed once existing legacy
users are converted to DT.
Cc: Jassi Brar jassisinghb...@gmail.com
Cc: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Suman Anna s-a...@ti.com
---
v3-v4: No code changes, switched the example to use the DSP node instead of
WkupM3 in the bindings document minor commit description changes. Other than
that, this is a repost of the driver adaptation patch [1] from the OMAP
Mailbox
framework adaptation series [2]. This patch is intended for the 3.19 merge
window,
all the dependent patches in [2] are merged as of 3.18-rc2. The DTS patch in
[2]
will be posted separately.
[1] http://marc.info/?l=linux-omapm=141038453917790w=2
[2] http://marc.info/?l=linux-omapm=141038447817775w=2
.../devicetree/bindings/mailbox/omap-mailbox.txt | 23 ++
drivers/mailbox/omap-mailbox.c | 346
-
drivers/remoteproc/omap_remoteproc.c | 51 +--
include/linux/omap-mailbox.h | 16 +-
4 files changed, 256 insertions(+), 180 deletions(-)
diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
index 48edc4b..d1a0433 100644
--- a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -43,6 +43,9 @@ Required properties:
device. The format is dependent on which interrupt
controller the OMAP device uses
- ti,hwmods: Name of the hwmod associated with the mailbox
+- #mbox-cells: Common mailbox binding property to identify the number
+ of cells required for the mailbox specifier. Should be
+ 1
- ti,mbox-num-users: Number of targets (processor devices) that the mailbox
device can interrupt
- ti,mbox-num-fifos: Number of h/w fifo queues within the mailbox IP block
@@ -72,6 +75,18 @@ data that represent the following:
Cell #3 (usr_id) - mailbox user id for identifying the interrupt line
associated with generating a tx/rx fifo interrupt.
+Mailbox Users:
+==
+A device needing to communicate with a target processor device should specify
+them using the common mailbox binding properties, mboxes and the optional
+mbox-names (please see
Documentation/devicetree/bindings/mailbox/mailbox.txt
+for details). Each value of the mboxes property should contain a phandle to
the
+mailbox controller device node and an args specifier that will be the
phandle to
+the intended sub-mailbox child node to be used for communication. The
equivalent
+mbox-names property value can be used to give a name to the communication
channel
+to be used by the client user.
+
+
Example:
@@ -81,6 +96,7 @@ mailbox: mailbox@4a0f4000 {
reg = 0x4a0f4000 0x200;
interrupts = GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods =
Re: [PATCH v5 06/10] ARM: dts: am4372: Add DCAN nodes
On 11/22/2014 02:08 AM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [141121 15:52]: * Roger Quadros rog...@ti.com [141117 05:10]: The SoC contains 2 DCAN modules. Add them. Thanks applying all into omap-for-v3.19/dt-v2. Oops, have to drop these as they cause this on make dtbs: DTC arch/arm/boot/dts/dra7-evm.dtb Warning (reg_format): reg property in /soc/can@481cc000 has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (reg_format): reg property in /soc/can@481d has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481d Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481d DTC arch/arm/boot/dts/am57xx-beagle-x15.dtb Warning (reg_format): reg property in /soc/can@481cc000 has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (reg_format): reg property in /soc/can@481d has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481d Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481d DTC arch/arm/boot/dts/dra72-evm.dtb Warning (reg_format): reg property in /soc/can@481cc000 has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (reg_format): reg property in /soc/can@481d has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481d Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481d Care to update the patches for that and then do a pull request for me? I didn't see these warnings on 3.18-rc1 though. Looks like some new checks were added in -next. I'll fix these and send you an updated pull request. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] memory: gpmc: Move omap gpmc code to live under drivers
Tony, On 11/21/2014 08:34 PM, Tony Lindgren wrote: Just move to drivers as further clean-up can now happen there finally. Let's also add Roger and me to the MAINTAINERS so we get notified for any patches related to GPMC. Cc: Arnd Bergmann a...@arndb.de Cc: Roger Quadros rog...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- MAINTAINERS | 8 arch/arm/mach-omap2/Kconfig | 2 ++ arch/arm/mach-omap2/Makefile | 2 +- drivers/memory/Kconfig | 8 drivers/memory/Makefile | 1 + arch/arm/mach-omap2/gpmc.c = drivers/memory/omap-gpmc.c | 0 6 files changed, 20 insertions(+), 1 deletion(-) rename arch/arm/mach-omap2/gpmc.c = drivers/memory/omap-gpmc.c (100%) diff --git a/MAINTAINERS b/MAINTAINERS index dab92a7..78cc059 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6629,6 +6629,14 @@ L: linux-omap@vger.kernel.org S: Maintained F: sound/soc/omap/ +OMAP GENERAL PURPOSE MEMORY CONTROLLER SUPPORT +M: Roger Quadros rog...@ti.com +M: Tony Lindgren t...@atomide.com +L: linux-omap@vger.kernel.org +S: Maintained +F: drivers/memory/omap-gpmc.c +F: arch/arm/mach-omap2/*gpmc* + OMAP FRAMEBUFFER SUPPORT M: Tomi Valkeinen tomi.valkei...@ti.com L: linux-fb...@vger.kernel.org diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f4d06ae..0ea218e 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -79,7 +79,9 @@ config ARCH_OMAP2PLUS select CLKSRC_MMIO select GENERIC_IRQ_CHIP select MACH_OMAP_GENERIC + select MEMORY select OMAP_DM_TIMER + select OMAP_GPMC select PINCTRL select SOC_BUS select TI_PRIV_EDMA diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 3e824f8..bd85741 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -6,7 +6,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \ -I$(srctree)/arch/arm/plat-omap/include # Common support -obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o gpmc.o timer.o pm.o \ +obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o timer.o pm.o \ common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \ omap_device.o sram.o drm.o diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index 6d91c27..6759de7 100644 --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -41,6 +41,14 @@ config TI_EMIF parameters and other settings during frequency, voltage and temperature changes +config OMAP_GPMC + bool We should depend on ARCH_OMAP2PLUS. Other platforms won't benefit anything from this driver. + help + This driver is for the General Purpose Memory Controller (GPMC) + present on Texas Instruments SoCs (e.g. OMAP2+). GPMC allows + interfacing to a variety of asynchronous as well as synchronous + memory drives like NOR, NAND, OneNAND, SRAM. + config MVEBU_DEVBUS bool Marvell EBU Device Bus Controller default y diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile index c32d319..a7d410f 100644 --- a/drivers/memory/Makefile +++ b/drivers/memory/Makefile @@ -8,6 +8,7 @@ endif obj-$(CONFIG_ATMEL_SDRAMC) += atmel-sdramc.o obj-$(CONFIG_TI_AEMIF) += ti-aemif.o obj-$(CONFIG_TI_EMIF)+= emif.o +obj-$(CONFIG_OMAP_GPMC) += omap-gpmc.o obj-$(CONFIG_FSL_CORENET_CF) += fsl-corenet-cf.o obj-$(CONFIG_FSL_IFC)+= fsl_ifc.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o diff --git a/arch/arm/mach-omap2/gpmc.c b/drivers/memory/omap-gpmc.c similarity index 100% rename from arch/arm/mach-omap2/gpmc.c rename to drivers/memory/omap-gpmc.c cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
On Mon, Nov 24, 2014 at 09:57:46AM +0100, Sebastian Andrzej Siewior wrote: On 11/21/2014 02:10 PM, Richard Cochran wrote: On the BB white using the LCD4 cape and the shipped debian kernel, the cursor *does* jump away, but not as often or as far as on the custom design I was working with. This sounds like the ADC is still sampling while the input data becomes invalid. Usually there is a resistor on the wiper line and the touchscreen manual says how much it should be at least. Could you please check if this is properly installed? Wiper line? This is a four wire device. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 06/10] ARM: dts: am4372: Add DCAN nodes
On 11/24/2014 11:58 AM, Roger Quadros wrote: On 11/22/2014 02:08 AM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [141121 15:52]: * Roger Quadros rog...@ti.com [141117 05:10]: The SoC contains 2 DCAN modules. Add them. Thanks applying all into omap-for-v3.19/dt-v2. Oops, have to drop these as they cause this on make dtbs: DTC arch/arm/boot/dts/dra7-evm.dtb Warning (reg_format): reg property in /soc/can@481cc000 has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (reg_format): reg property in /soc/can@481d has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481d Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481d DTC arch/arm/boot/dts/am57xx-beagle-x15.dtb Warning (reg_format): reg property in /soc/can@481cc000 has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (reg_format): reg property in /soc/can@481d has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481d Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481d DTC arch/arm/boot/dts/dra72-evm.dtb Warning (reg_format): reg property in /soc/can@481cc000 has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (reg_format): reg property in /soc/can@481d has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481d Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481d Care to update the patches for that and then do a pull request for me? I didn't see these warnings on 3.18-rc1 though. Looks like some new checks were added in -next. I'll fix these and send you an updated pull request. I couldn't reproduce the errors on linux-next nor on your branch. Maybe you had a conflict resolution issue? I've rebased the patches on omap-for-v3.19/dt-v2 and are available for you to pull from: The following changes since commit 0f39f7b906dbeabe2ffd8739d5201e890d102ea6: ARM: dts: AM43xx: add tscadc DT entries for am437x-evm and am43x-epos-evm (2014-11-21 16:25:06 -0800) are available in the git repository at: g...@github.com:rogerq/linux.git for-v3.19/omap-dts-dcan for you to fetch changes up to bae6665b8002282a833bf482b242e7df5d63b3d3: ARM: dts: am335x-evm: Add DCAN1 details (2014-11-24 12:41:17 +0200) Mugunthan V N (1): arm: dts: am437x-gp: Add dcan support Roger Quadros (9): ARM: dts: dra7: Add syscon regmap for CORE CONTROL area ARM: dts: DRA7: Add DCAN nodes ARM: dts: dra7-evm: Add CAN support ARM: dts: dra72-evm: Add CAN support ARM: dts: am4372: Add control module syscon node ARM: dts: am4372: Add DCAN nodes ARM: dts: am33xx: Add control module syscon node ARM: dts: am33xx: Update DCAN nodes ARM: dts: am335x-evm: Add DCAN1 details arch/arm/boot/dts/am335x-evm.dts| 13 + arch/arm/boot/dts/am33xx.dtsi | 25 + arch/arm/boot/dts/am4372.dtsi | 27 +++ arch/arm/boot/dts/am437x-gp-evm.dts | 26 ++ arch/arm/boot/dts/dra7-evm.dts | 22 ++ arch/arm/boot/dts/dra7.dtsi | 26 ++ arch/arm/boot/dts/dra72-evm.dts | 23 +++ 7 files changed, 154 insertions(+), 8 deletions(-) -- cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: omap2plus_defconfig: Enable AHCI_PLATFORM driver
OMAP5 and DRA7 platforms need the AHCI platform driver for SATA support. Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/configs/omap2plus_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 87a5c11..d75358a 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -127,6 +127,8 @@ CONFIG_SRAM=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SCSI_SCAN_ASYNC=y +CONFIG_ATA=y +CONFIG_SATA_AHCI_PLATFORM=y CONFIG_MD=y CONFIG_NETDEVICES=y # CONFIG_NET_VENDOR_ARC is not set -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] video: omapdss: Add opa362 driver
On 19/11/14 17:10, Dr. H. Nikolaus Schaller wrote:
You don't need to ask. The connector calls invert_vid_out_polarity
before enabling the output.
Unfortunately it doesn’t. At least not always.
It does only for pdata systems but not for DT based systems:
if (!ddata-dev-of_node) {
in-ops.atv-set_type(in, ddata-connector_type);
in-ops.atv-invert_vid_out_polarity(in,
ddata-invert_polarity);
}
Not calling is in our case different from calling with ddata-invert_polarity
== 0.
Ah, sorry, my mistake. I should've read the code more carefully =).
So, with DT only approach, those calls above are not supported. If you
make the OPA driver DT only, you can remove those functions.
You only need to set the invert-polarity property in the venc DT node.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v4 0/6] Touchscreen performance related fixes
* Vignesh R | 2014-11-14 10:37:25 [+0530]: This series of patches fix TSC defects related to lag in touchscreen performance and cursor jump at touch release. The lag was result of udelay in TSC interrupt handler. Cursor jump due to false pen-up event. The patches implement Advisory 1.0.31 in silicon errata of am335x-evm am335x not -evm. The am335x-evm is a board (with its own advisory document) built around the SoC. Just testing the v4. I can use now IIO and touchscren at the same time. back at v1 I reported that it does not work, this has been fixed now. I had it running for a few minutes, now I see one of WARN_ON() beeing triggered (I've cut a few numbers so don't wonder about PID 2 and so on): |dmesg |grep WARNING | wc -l |10 | dmesg |grep WARNING |[306.257995] WARNING: CPU: 0 PID: 97 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[365.469591] WARNING: CPU: 0 PID: 58 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[379.255904] WARNING: CPU: 0 PID: 24 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[426.230505] WARNING: CPU: 0 PID: 35 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[435.654091] WARNING: CPU: 0 PID: 28 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[438.897519] WARNING: CPU: 0 PID: 91 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[525.720193] WARNING: CPU: 0 PID: 88 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[527.644770] WARNING: CPU: 0 PID: 38 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[557.218349] WARNING: CPU: 0 PID: 56 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[610.077274] WARNING: CPU: 0 PID: 2 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 The complete trace: |[610.110692] CPU: 0 PID: 4422 Comm: cat Tainted: GW 3.18.0-rc6+ #1745 |[610.118577] [c00138ec] (unwind_backtrace) from [c0011544] (show_stack+0x10/0x14) |[610.126772] [c0011544] (show_stack) from [c003c9b0] (warn_slowpath_common+0x68/0x88) |[610.135313] [c003c9b0] (warn_slowpath_common) from [c003c9ec] (warn_slowpath_null+0x1c/0x24) |[610.144586] [c003c9ec] (warn_slowpath_null) from [bf00569c] (am335x_tsc_se_set_once+0xf8/0x104 [ti_am335x_tscadc]) |[610.155886] [bf00569c] (am335x_tsc_se_set_once [ti_am335x_tscadc]) from [bf067494] (tiadc_read_raw+0xbc/0x190 [ti_am335x_adc]) |[610.168326] [bf067494] (tiadc_read_raw [ti_am335x_adc]) from [bf02dccc] (iio_read_channel_info+0x9c/0xa4 [industrialio]) |[610.180191] [bf02dccc] (iio_read_channel_info [industrialio]) from [c02a42d4] (dev_attr_show+0x1c/0x48) |[610.190477] [c02a42d4] (dev_attr_show) from [c013d544] (sysfs_kf_seq_show+0x8c/0x110) |[610.199108] [c013d544] (sysfs_kf_seq_show) from [c013c1c8] (kernfs_seq_show+0x24/0x28) |[610.207833] [c013c1c8] (kernfs_seq_show) from [c0102658] (seq_read+0x1b4/0x47c) |[610.215922] [c0102658] (seq_read) from [c00e6700] (vfs_read+0x8c/0x148) |[610.223269] [c00e6700] (vfs_read) from [c00e67fc] (SyS_read+0x40/0x8c) |[610.230525] [c00e67fc] (SyS_read) from [c000e640] (ret_fast_syscall+0x0/0x30) Could you please look at that one? (I tested it on am335x-evm btw). Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/6] Touchscreen performance related fixes
On Monday 24 November 2014 05:21 PM, Sebastian Andrzej Siewior wrote: * Vignesh R | 2014-11-14 10:37:25 [+0530]: This series of patches fix TSC defects related to lag in touchscreen performance and cursor jump at touch release. The lag was result of udelay in TSC interrupt handler. Cursor jump due to false pen-up event. The patches implement Advisory 1.0.31 in silicon errata of am335x-evm am335x not -evm. The am335x-evm is a board (with its own advisory document) built around the SoC. Just testing the v4. I can use now IIO and touchscren at the same time. back at v1 I reported that it does not work, this has been fixed now. I had it running for a few minutes, now I see one of WARN_ON() beeing triggered (I've cut a few numbers so don't wonder about PID 2 and so on): |dmesg |grep WARNING | wc -l |10 | dmesg |grep WARNING |[306.257995] WARNING: CPU: 0 PID: 97 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[365.469591] WARNING: CPU: 0 PID: 58 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[379.255904] WARNING: CPU: 0 PID: 24 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[426.230505] WARNING: CPU: 0 PID: 35 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[435.654091] WARNING: CPU: 0 PID: 28 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[438.897519] WARNING: CPU: 0 PID: 91 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[525.720193] WARNING: CPU: 0 PID: 88 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[527.644770] WARNING: CPU: 0 PID: 38 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[557.218349] WARNING: CPU: 0 PID: 56 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 |[610.077274] WARNING: CPU: 0 PID: 2 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104 The complete trace: |[610.110692] CPU: 0 PID: 4422 Comm: cat Tainted: GW 3.18.0-rc6+ #1745 |[610.118577] [c00138ec] (unwind_backtrace) from [c0011544] (show_stack+0x10/0x14) |[610.126772] [c0011544] (show_stack) from [c003c9b0] (warn_slowpath_common+0x68/0x88) |[610.135313] [c003c9b0] (warn_slowpath_common) from [c003c9ec] (warn_slowpath_null+0x1c/0x24) |[610.144586] [c003c9ec] (warn_slowpath_null) from [bf00569c] (am335x_tsc_se_set_once+0xf8/0x104 [ti_am335x_tscadc]) |[610.155886] [bf00569c] (am335x_tsc_se_set_once [ti_am335x_tscadc]) from [bf067494] (tiadc_read_raw+0xbc/0x190 [ti_am335x_adc]) |[610.168326] [bf067494] (tiadc_read_raw [ti_am335x_adc]) from [bf02dccc] (iio_read_channel_info+0x9c/0xa4 [industrialio]) |[610.180191] [bf02dccc] (iio_read_channel_info [industrialio]) from [c02a42d4] (dev_attr_show+0x1c/0x48) |[610.190477] [c02a42d4] (dev_attr_show) from [c013d544] (sysfs_kf_seq_show+0x8c/0x110) |[610.199108] [c013d544] (sysfs_kf_seq_show) from [c013c1c8] (kernfs_seq_show+0x24/0x28) |[610.207833] [c013c1c8] (kernfs_seq_show) from [c0102658] (seq_read+0x1b4/0x47c) |[610.215922] [c0102658] (seq_read) from [c00e6700] (vfs_read+0x8c/0x148) |[610.223269] [c00e6700] (vfs_read) from [c00e67fc] (SyS_read+0x40/0x8c) |[610.230525] [c00e67fc] (SyS_read) from [c000e640] (ret_fast_syscall+0x0/0x30) Could you please look at that one? (I tested it on am335x-evm btw). I have tried running both IIO and TSC at the same time. But I have never seen WARN_ON() even after running for close to 30 min. Can you send me the exact script, so that it will be easy to reproduce? Regards Vignesh Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/6] Touchscreen performance related fixes
On 11/24/2014 01:16 PM, Vignesh R wrote: I have tried running both IIO and TSC at the same time. But I have never seen WARN_ON() even after running for close to 30 min. Can you send me the exact script, so that it will be easy to reproduce? Sure thing. - one shell evtest /dev/input/event2 - second shell ./iio-test.sh with: |#!/bin/sh | |while [ 1 = 1 ] |do |cat /sys/bus/iio/devices/iio\:device0/in_voltage4_raw |done the kernel config: https://breakpoint.cc/am335x-config Regards Vignesh Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On 11/21/2014 06:38 PM, Mark Brown wrote: On Fri, Nov 21, 2014 at 02:10:11PM +0200, Jyri Sarha wrote: OMAP HDMI audio is fundamentally different to the case on Armada or on BBB. In omap the whole HDMI IP is integrated to the SoC and there really is no codec in the ASoC sense. The the cpu-dai transmits the audio directly to hdmi wire and there is no i2s bus involved. So this case should not be mixed with the patches Jean-Francois working on. The code is also orthogonal in that sense that the latest omap-hdmi-audio uses the generic dymmy codec. The discussion seemed to be about what to do with unplugged connections which isn't what you're talking about there and does seem like an area where we should at least be aiming for common behaviour even if not a common implementation. In the discussion we recognized three modes of operation, a) try to keep audio device always operational even if audio is not going anywhere (cable is disconnected or video mode does not support audio) b) remove the audio device when audio is not available c) disable audio device if audio is not available and abort any ongoing stream when audio becomes unavailable d) force pause on the stream when audio is not available The implementation in the patches follows mode c) and in my mind it makes the most sense. The mode is not carved into stone by the current implementation and it can be changed if we decide so. I see no point in keeping the hdmi audio completely broken until we collectively decide on how all HDMI audio devices should behave. There's also all the stuff about parsing EDIDs for capabilities which would seem to be related to that but seems to have gone off into the weeds. The idea of the patch set is to restore the old hdmi audio functionality in a form that is easier to use and maintain. Additional functionality can be added later. For instance restricting the allowed sample rates etc. based EDID Short Audio Descriptors. Best regards, Jyri -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] memory: gpmc: Move omap gpmc code to live under drivers
* Roger Quadros rog...@ti.com [141124 02:02]: On 11/21/2014 08:34 PM, Tony Lindgren wrote: --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -41,6 +41,14 @@ config TI_EMIF parameters and other settings during frequency, voltage and temperature changes +config OMAP_GPMC + bool We should depend on ARCH_OMAP2PLUS. Other platforms won't benefit anything from this driver. We can't do that yet until we have sorted out the remaining platform data issues with arch/arm/mach-omap2/*gpmc*.c files. So OMAP_GPMC is currently a silent Kconfig option that does not show up as the description after the bool is not there, we select OMAP_GPMC automatically based on ARCH_OMAP2PLUS. Once we have the remaining legacy code issues sorted out, we can make this into just a regular device driver. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 06/10] ARM: dts: am4372: Add DCAN nodes
* Roger Quadros rog...@ti.com [141124 03:13]: I couldn't reproduce the errors on linux-next nor on your branch. Maybe you had a conflict resolution issue? I guess it must have been a conflict resolution issue at my end then. I've rebased the patches on omap-for-v3.19/dt-v2 and are available for you to pull from: The following changes since commit 0f39f7b906dbeabe2ffd8739d5201e890d102ea6: ARM: dts: AM43xx: add tscadc DT entries for am437x-evm and am43x-epos-evm (2014-11-21 16:25:06 -0800) are available in the git repository at: g...@github.com:rogerq/linux.git for-v3.19/omap-dts-dcan Pulling into omap-for-v3.19/dts thanks. Let's also switch into fixes only mode for v3.19 now with -rc6 out. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] ARM: dts: sbc-t3x: add audio and TV out support
* Dmitry Lifshitz lifsh...@compulab.co.il [141123 01:44]: Add support for more SBC-T3x single board computers features: * Audio on CM-T3x30 * TV out on CM-T3x This patch set adds missing I2C1 pinmux required for CM-T3x EEPROM and CM-T3x30 audio support. Thanks applying into omap-for-v3.19/dt-v2. Let's also do fixes only for v3.19 from now on as -rc6 is tagged. Regards, Tony Dmitry Lifshitz (4): ARM: dts: cm-t3x: add I2C1 pinmux ARM: dts: cm-t3x: add TV out support ARM: dts: sbc-t3x: add TV out display alias ARM: dts: sbc-t3x30: add audio support arch/arm/boot/dts/omap3-cm-t3x.dtsi | 48 + arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 18 arch/arm/boot/dts/omap3-sb-t35.dtsi | 16 +++ arch/arm/boot/dts/omap3-sbc-t3517.dts |1 + arch/arm/boot/dts/omap3-sbc-t3530.dts |1 + arch/arm/boot/dts/omap3-sbc-t3730.dts |1 + 6 files changed, 85 insertions(+), 0 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
TLV320AIC3104 Sample rate problem
Hello, I'm using an Audio Cape Rev. B connected to BeagleBone Black (MCLK=12MHz) and I'm trying to record audio at sample rate 8KHz. Recording and playback using ALSA is OK, but when playing the recorded samples on PC you can hear that the actual sample rate is lower (the pitch shifted to a lower tone). I have added debug messages throughout the alsa driver tlv320aic3x.c, and I found out that the PLL parameters are computed correctly as in TLV320AIC3104 Datasheet Table found at page 27. (p: 1 j: 8 d: 1920 r: 1). Has anyone else encountered a problem like this? Can someone with more experience check the driver? Kernel: https://github.com/beagleboard/linux , commit 2bcc89c, 3.14.19+. Best regards, Catalin Crenguta -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 06/10] ARM: dts: am4372: Add DCAN nodes
* Tony Lindgren t...@atomide.com [141124 07:49]: * Roger Quadros rog...@ti.com [141124 03:13]: I couldn't reproduce the errors on linux-next nor on your branch. Maybe you had a conflict resolution issue? I guess it must have been a conflict resolution issue at my end then. I've rebased the patches on omap-for-v3.19/dt-v2 and are available for you to pull from: The following changes since commit 0f39f7b906dbeabe2ffd8739d5201e890d102ea6: ARM: dts: AM43xx: add tscadc DT entries for am437x-evm and am43x-epos-evm (2014-11-21 16:25:06 -0800) are available in the git repository at: g...@github.com:rogerq/linux.git for-v3.19/omap-dts-dcan Pulling into omap-for-v3.19/dts thanks. Let's also switch into fixes only mode for v3.19 now with -rc6 out. Knowing you most likely don't have anything else based on this branch, I ended up just picking the patches from your branch to unify the subject line for one of the patches. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 2/2] part 2 of omap dts changes for v3.19
Hi, Just noticed I have the signed tag missing for this one, updated pull request below. * Tony Lindgren t...@atomide.com [141122 16:47]: The following changes since commit 065bd7fe50de5e6d0fd5034cbc87120a558a1219: ARM: dts: DRA7: Add aliases for all serial ports (2014-11-12 07:04:37 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap omap-for-v3.19/dt-v2 So please ignore the pull request above, below is an updated pull request with a proper tag. I've also added few more patches that I could not apply earlier because of pending comments. The following changes since commit 065bd7fe50de5e6d0fd5034cbc87120a558a1219: ARM: dts: DRA7: Add aliases for all serial ports (2014-11-12 07:04:37 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.19/dt-part2-updated for you to fetch changes up to f80ecaf55b4982a888272790743dabf2c715dc10: ARM: dts: am335x-evm: Add DCAN1 details (2014-11-24 07:56:22 -0800) More dts changes for omaps to add support for new devices: - Add DCAN support am335x, am437x and dra7 - Add devices for sb-t3x computers - Add support for NovaTech OrionLXm - Add n900 battery and si4713 support Adam YH Lee (1): ARM: dts: Gumstix DuoVero: Bind vdac regulator to hdmi node Dmitry Lifshitz (10): ARM: dts: cm-t3x: cleanup comments indentation ARM: dts: cm-t3x: add ADS7846 touchscreen support ARM: OMAP2+: remove cm-t3x touchscreen pdata quirk ARM: dts: cm-t3x: add EEPROM support ARM: dts: sb-t35: add EEPROM support ARM: dts: cm-t3x30: add keypad support ARM: dts: cm-t3x: add I2C1 pinmux ARM: dts: cm-t3x: add TV out support ARM: dts: sbc-t3x: add TV out display alias ARM: dts: sbc-t3x30: add audio support George McCollister (1): ARM: dts: Add devicetree for NovaTech OrionLXm Lokesh Vutla (1): ARM: dts: DRA7: Add node for RTC Mugunthan V N (1): ARM: dts: am437x-gp: Add dcan support Roger Quadros (9): ARM: dts: dra7: Add syscon regmap for CORE CONTROL area ARM: dts: DRA7: Add DCAN nodes ARM: dts: dra7-evm: Add CAN support ARM: dts: dra72-evm: Add CAN support ARM: dts: am4372: Add control module syscon node ARM: dts: am4372: Add DCAN nodes ARM: dts: am33xx: Add control module syscon node ARM: dts: am33xx: Update DCAN nodes ARM: dts: am335x-evm: Add DCAN1 details Sebastian Reichel (2): ARM: dts: OMAP3-N900: add si4713 support ARM: dst: OMAP3-N900: Add n900-battery support Vignesh R (1): ARM: dts: AM43xx: add tscadc DT entries for am437x-evm and am43x-epos-evm .../devicetree/bindings/arm/omap/omap.txt | 3 + arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/am335x-evm.dts | 13 + arch/arm/boot/dts/am335x-lxm.dts | 362 + arch/arm/boot/dts/am33xx.dtsi | 25 +- arch/arm/boot/dts/am4372.dtsi | 47 +++ arch/arm/boot/dts/am437x-gp-evm.dts| 34 ++ arch/arm/boot/dts/am43x-epos-evm.dts | 8 + arch/arm/boot/dts/dra7-evm.dts | 22 ++ arch/arm/boot/dts/dra7.dtsi| 35 ++ arch/arm/boot/dts/dra72-evm.dts| 23 ++ arch/arm/boot/dts/omap3-cm-t3x.dtsi| 124 ++- arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 35 ++ arch/arm/boot/dts/omap3-n900.dts | 16 + arch/arm/boot/dts/omap3-sb-t35.dtsi| 36 ++ arch/arm/boot/dts/omap3-sbc-t3517.dts | 1 + arch/arm/boot/dts/omap3-sbc-t3530.dts | 1 + arch/arm/boot/dts/omap3-sbc-t3730.dts | 1 + arch/arm/boot/dts/omap4-duovero-parlor.dts | 1 + arch/arm/mach-omap2/pdata-quirks.c | 3 - 20 files changed, 775 insertions(+), 18 deletions(-) create mode 100644 arch/arm/boot/dts/am335x-lxm.dts -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On Mon, Nov 24, 2014 at 10:18:31AM +0200, Tomi Valkeinen wrote: On 21/11/14 18:14, Mark Brown wrote: But in what way is it broken and how did this happen? Why are none of I don't have a clear answer, but it probably involves lack of use, and buggy and hard to use implementation. Things have changed around the original HDMI audio implementation, and it stopped working at some point. As the original implementation was found rather lacking, and with some fundamental issues, it was deemed better to have a fresh approach. OK... this is all telling me that I *really* need to scrub this in detail. It's all sounding very vague, it's an area which seems to cause lots of problems and I don't want to be sitting here next time around trying to figure out if another rewrite makes things better or worse or if another driver should look similar or different. the patches which look like they're supposed to be bug fixes early on in the series getting applied? I had thought this was just a lack of interest on the video side but it seems there's some other problems since the series has apparently been discussed off-list and still it's just as big as it was initially. The whole series is about HDMI audio, not video. You know exactly what I mean - the early patches are in drivers/video, don't touch anything outside of that and have no obvious dependencies. This series only touch the parts about HDMI audio, so the fixes early on don't really fix anything without the rest of the series (as the current HDMI audio doesn't work). And in any case, I don't like applying individual patches from a series. Usually that just complicates things. If I would apply some of the early patches to fbdev, then this series would no longer work on plain mainline kernel, and would instead depend on fbdev tree. The situation But I thought everyone was saying this hardware doesn't work anyway and that you want to apply all these changes to fbdev? would be ever worse if you'd also pick some of the audio patches to sound tree, creating a dependency to two subsystem trees. So if there's no particular important reason to pick patches from a series, I rather keep it as a whole to simplify merging and testing. This means we're all then stuck reading reposts of the same enormous series over and over again - as a reviewer a really big series that appears from the subject lines to be mostly about another system is really offputting. If you're going to do something like this please at least reply to the messages, that way it's clearer that there's not going to be a dependency problem getting the patches applied (which is part of what makes things offputting). signature.asc Description: Digital signature
v3.18-rc1: n900 battery discharged down to 2.97V
Hi! I left the machine on usb-networking for extended period of time. Unfortunately, Xfce screensaver kept screen busy, and kernel failed to kill the machine. At the end, hardware protections worked (I guess), but result is battery discharged down to 2.97V. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ASoC: tlv320aic31xx: Fix off by one error in the loop stucture.
Fix off by one read beyond the end of a table.
Reported-by: David Binderman dcb...@hotmail.com
Signed-off-by: Jyri Sarha jsa...@ti.com
---
sound/soc/codecs/tlv320aic31xx.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c
index 145fe5b..93de5dd 100644
--- a/sound/soc/codecs/tlv320aic31xx.c
+++ b/sound/soc/codecs/tlv320aic31xx.c
@@ -911,12 +911,13 @@ static int aic31xx_set_dai_sysclk(struct snd_soc_dai
*codec_dai,
}
aic31xx-p_div = i;
- for (i = 0; aic31xx_divs[i].mclk_p != freq/aic31xx-p_div; i++) {
- if (i == ARRAY_SIZE(aic31xx_divs)) {
- dev_err(aic31xx-dev, %s: Unsupported frequency %d\n,
- __func__, freq);
- return -EINVAL;
- }
+ for (i = 0; i ARRAY_SIZE(aic31xx_divs)
+aic31xx_divs[i].mclk_p != freq/aic31xx-p_div; i++)
+ ;
+ if (i == ARRAY_SIZE(aic31xx_divs)) {
+ dev_err(aic31xx-dev, %s: Unsupported frequency %d\n,
+ __func__, freq);
+ return -EINVAL;
}
/* set clock on MCLK, BCLK, or GPIO1 as PLL input */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v3.18-rc1: n900 battery discharged down to 2.97V
On Mon 2014-11-24 19:58:34, Pali Rohár wrote: On Monday 24 November 2014 19:31:30 Pavel Machek wrote: Hi! I left the machine on usb-networking for extended period of time. Unfortunately, Xfce screensaver kept screen busy, and kernel failed to kill the machine. At the end, hardware protections worked (I guess), but result is battery discharged down to 2.97V. So you need some program which will monitor battery status and when battery status is empty it should turn of device. And that program should be part of the kernel, because kernel should protect hardware from damage. (And it should be perfectly ok to boot into init=/bin/bash...) Anyway, this was just friendly warning, so that you don't unneccessarily damage your battery... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] usb: musb: Change end point selection to use new IO access
This allows the endpoints to work when multiple MUSB glue
layers are built in.
Cc: Fabio Baltieri fabio.balti...@linaro.org
Cc: Lee Jones lee.jo...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Apelete Seketeli apel...@seketeli.net
Cc: Lars-Peter Clausen l...@metafoo.de
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/usb/musb/am35x.c | 1 +
drivers/usb/musb/da8xx.c | 1 +
drivers/usb/musb/jz4740.c| 1 +
drivers/usb/musb/musb_core.c | 38 +-
drivers/usb/musb/musb_core.h | 37 +
drivers/usb/musb/musb_dsps.c | 1 +
drivers/usb/musb/musb_io.h | 2 ++
drivers/usb/musb/musb_regs.h | 11 ---
drivers/usb/musb/musbhsdma.c | 7 ---
drivers/usb/musb/tusb6010.c | 13 +
drivers/usb/musb/ux500.c | 1 +
11 files changed, 62 insertions(+), 51 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 13d1d77..1ea4a67 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -438,6 +438,7 @@ static void am35x_read_fifo(struct musb_hw_ep *hw_ep, u16
len, u8 *dst)
}
static const struct musb_platform_ops am35x_ops = {
+ .quirks = MUSB_INDEXED_EP,
.init = am35x_musb_init,
.exit = am35x_musb_exit,
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 058775e..c9079c8 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -458,6 +458,7 @@ static int da8xx_musb_exit(struct musb *musb)
}
static const struct musb_platform_ops da8xx_ops = {
+ .quirks = MUSB_INDEXED_EP,
.init = da8xx_musb_init,
.exit = da8xx_musb_exit,
diff --git a/drivers/usb/musb/jz4740.c b/drivers/usb/musb/jz4740.c
index d118729..40e9874 100644
--- a/drivers/usb/musb/jz4740.c
+++ b/drivers/usb/musb/jz4740.c
@@ -106,6 +106,7 @@ static int jz4740_musb_exit(struct musb *musb)
}
static const struct musb_platform_ops jz4740_musb_ops = {
+ .quirks = MUSB_INDEXED_EP,
.init = jz4740_musb_init,
.exit = jz4740_musb_exit,
};
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2fbe149..48ddc82 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -229,6 +229,27 @@ static u32 musb_default_fifo_offset(u8 epnum)
return 0x20 + (epnum * 4);
}
+/* flat mapping: each endpoint has its own i/o address */
+static void musb_flat_ep_select(void __iomem *mbase, u8 epnum)
+{
+}
+
+static u32 musb_flat_ep_offset(u8 epnum, u16 offset)
+{
+ return 0x100 + (0x10 * epnum) + offset;
+}
+
+/* indexed mapping: INDEX register controls register bank select */
+static void musb_indexed_ep_select(void __iomem *mbase, u8 epnum)
+{
+ musb_writeb(mbase, MUSB_INDEX, epnum);
+}
+
+static u32 musb_indexed_ep_offset(u8 epnum, u16 offset)
+{
+ return 0x10 + offset;
+}
+
static u8 musb_default_readb(const void __iomem *addr, unsigned offset)
{
return __raw_readb(addr + offset);
@@ -1534,7 +1555,7 @@ static int musb_core_init(u16 musb_type, struct musb
*musb)
}
#endif
- hw_ep-regs = MUSB_EP_OFFSET(i, 0) + mbase;
+ hw_ep-regs = musb-io.ep_offset(i, 0) + mbase;
hw_ep-target_regs = musb_read_target_reg_base(i, mbase);
hw_ep-rx_reinit = 1;
hw_ep-tx_reinit = 1;
@@ -2004,6 +2025,21 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
if (musb-ops-quirks)
musb-io.quirks = musb-ops-quirks;
+ /* At least tusb6010 has it's own offsets.. */
+ if (musb-ops-ep_offset)
+ musb-io.ep_offset = musb-ops-ep_offset;
+ if (musb-ops-ep_select)
+ musb-io.ep_select = musb-ops-ep_select;
+
+ /* ..and some devices use indexed offset or flat offset */
+ if (musb-io.quirks MUSB_INDEXED_EP) {
+ musb-io.ep_offset = musb_indexed_ep_offset;
+ musb-io.ep_select = musb_indexed_ep_select;
+ } else {
+ musb-io.ep_offset = musb_flat_ep_offset;
+ musb-io.ep_select = musb_flat_ep_select;
+ }
+
if (musb-ops-fifo_offset)
musb-io.fifo_offset = musb-ops-fifo_offset;
else
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7c7f38c..02f62cb 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -124,41 +124,6 @@ enum musb_g_ep0_state {
#define OTG_TIME_A_AIDL_BDIS 200 /* min 200 msec */
#define OTG_TIME_B_ASE0_BRST 100 /* min 3.125 ms */
-
-/*** REGISTER ACCESS /
-
-/* Endpoint registers (other than dynfifo setup) can be accessed either
- * directly with the flat model, or after setting up an index register.
- */
-
-#if defined(CONFIG_ARCH_DAVINCI)
[PATCH 8/8] usb: musb: Use IS_ENABLED for tusb6010
This removes the ifdef clutter a bit and saves few lines.
It also makes it easier to detect the remaining places
where we have conditional building of code done based
on if defined for things like DMA.
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/usb/musb/musb_core.c | 2 +-
drivers/usb/musb/musb_core.h | 9 +++--
drivers/usb/musb/musb_regs.h | 3 ---
3 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0875365..0f44676 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1527,7 +1527,7 @@ static int musb_core_init(u16 musb_type, struct musb
*musb)
struct musb_hw_ep *hw_ep = musb-endpoints + i;
hw_ep-fifo = musb-io.fifo_offset(i) + mbase;
-#if defined(CONFIG_USB_MUSB_TUSB6010) || defined
(CONFIG_USB_MUSB_TUSB6010_MODULE)
+#if IS_ENABLED(CONFIG_USB_MUSB_TUSB6010)
if (musb-io.quirks MUSB_IN_TUSB) {
hw_ep-fifo_async = musb-async + 0x400 +
musb-io.fifo_offset(i);
hw_ep-fifo_sync = musb-sync + 0x400 +
musb-io.fifo_offset(i);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 02f62cb..841476c 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -216,8 +216,7 @@ struct musb_hw_ep {
void __iomem*fifo;
void __iomem*regs;
-#if defined(CONFIG_USB_MUSB_TUSB6010) || \
- defined(CONFIG_USB_MUSB_TUSB6010_MODULE)
+#if IS_ENABLED(CONFIG_USB_MUSB_TUSB6010)
void __iomem*conf;
#endif
@@ -234,8 +233,7 @@ struct musb_hw_ep {
struct dma_channel *tx_channel;
struct dma_channel *rx_channel;
-#if defined(CONFIG_USB_MUSB_TUSB6010) || \
- defined(CONFIG_USB_MUSB_TUSB6010_MODULE)
+#if IS_ENABLED(CONFIG_USB_MUSB_TUSB6010)
/* TUSB has asynchronous and synchronous dma modes */
dma_addr_t fifo_async;
dma_addr_t fifo_sync;
@@ -339,8 +337,7 @@ struct musb {
void __iomem*ctrl_base;
void __iomem*mregs;
-#if defined(CONFIG_USB_MUSB_TUSB6010) || \
- defined(CONFIG_USB_MUSB_TUSB6010_MODULE)
+#if IS_ENABLED(CONFIG_USB_MUSB_TUSB6010)
dma_addr_t async;
dma_addr_t sync;
void __iomem*sync_va;
diff --git a/drivers/usb/musb/musb_regs.h b/drivers/usb/musb/musb_regs.h
index 92b4c3d..11f0be0 100644
--- a/drivers/usb/musb/musb_regs.h
+++ b/drivers/usb/musb/musb_regs.h
@@ -287,10 +287,7 @@
#define MUSB_FIFOSIZE 0x0F
#define MUSB_CONFIGDATAMUSB_FIFOSIZE /* Re-used for EP0 */
-#if defined(CONFIG_USB_MUSB_TUSB6010) || \
- defined(CONFIG_USB_MUSB_TUSB6010_MODULE)
#include tusb6010.h /* Needed only for TUSB_EP0_CONF */
-#endif
#define MUSB_TXCSR_MODE0x2000
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] usb: musb: Pass fifo_mode in platform data
This allows setting the correct fifo_mode when multiple
MUSB glue layers are built-in.
Cc: Fabio Baltieri fabio.balti...@linaro.org
Cc: Lee Jones lee.jo...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Apelete Seketeli apel...@seketeli.net
Cc: Lars-Peter Clausen l...@metafoo.de
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/usb/musb/blackfin.c | 1 +
drivers/usb/musb/da8xx.c | 1 +
drivers/usb/musb/jz4740.c| 1 +
drivers/usb/musb/musb_core.c | 21 ++---
drivers/usb/musb/ux500.c | 1 +
5 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index c55fcfd..b8442b9 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -474,6 +474,7 @@ static const struct musb_platform_ops bfin_ops = {
.writew = bfin_writew,
.readl = bfin_readl,
.writel = bfin_writel,
+ .fifo_mode = 2,
.read_fifo = bfin_read_fifo,
.write_fifo = bfin_write_fifo,
.enable = bfin_musb_enable,
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index c9079c8..5f9b486 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -462,6 +462,7 @@ static const struct musb_platform_ops da8xx_ops = {
.init = da8xx_musb_init,
.exit = da8xx_musb_exit,
+ .fifo_mode = 2,
.enable = da8xx_musb_enable,
.disable= da8xx_musb_disable,
diff --git a/drivers/usb/musb/jz4740.c b/drivers/usb/musb/jz4740.c
index 40e9874..bb7b263 100644
--- a/drivers/usb/musb/jz4740.c
+++ b/drivers/usb/musb/jz4740.c
@@ -107,6 +107,7 @@ static int jz4740_musb_exit(struct musb *musb)
static const struct musb_platform_ops jz4740_musb_ops = {
.quirks = MUSB_INDEXED_EP,
+ .fifo_mode = 2,
.init = jz4740_musb_init,
.exit = jz4740_musb_exit,
};
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 48ddc82..0875365 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1116,21 +1116,7 @@ static void musb_shutdown(struct platform_device *pdev)
* We don't currently use dynamic fifo setup capability to do anything
* more than selecting one of a bunch of predefined configurations.
*/
-#if defined(CONFIG_USB_MUSB_TUSB6010) \
- || defined(CONFIG_USB_MUSB_TUSB6010_MODULE) \
- || defined(CONFIG_USB_MUSB_OMAP2PLUS) \
- || defined(CONFIG_USB_MUSB_OMAP2PLUS_MODULE)\
- || defined(CONFIG_USB_MUSB_AM35X) \
- || defined(CONFIG_USB_MUSB_AM35X_MODULE)\
- || defined(CONFIG_USB_MUSB_DSPS)\
- || defined(CONFIG_USB_MUSB_DSPS_MODULE)
-static ushort fifo_mode = 4;
-#elif defined(CONFIG_USB_MUSB_UX500) \
- || defined(CONFIG_USB_MUSB_UX500_MODULE)
-static ushort fifo_mode = 5;
-#else
-static ushort fifo_mode = 2;
-#endif
+static ushort fifo_mode;
/* modprobe ... fifo_mode=1 etc */
module_param(fifo_mode, ushort, 0);
@@ -2040,6 +2026,11 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
musb-io.ep_select = musb_flat_ep_select;
}
+ if (musb-ops-fifo_mode)
+ fifo_mode = musb-ops-fifo_mode;
+ else
+ fifo_mode = 4;
+
if (musb-ops-fifo_offset)
musb-io.fifo_offset = musb-ops-fifo_offset;
else
diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c
index c170501..c372518 100644
--- a/drivers/usb/musb/ux500.c
+++ b/drivers/usb/musb/ux500.c
@@ -191,6 +191,7 @@ static const struct musb_platform_ops ux500_ops = {
.quirks = MUSB_INDEXED_EP,
.init = ux500_musb_init,
.exit = ux500_musb_exit,
+ .fifo_mode = 5,
.set_vbus = ux500_musb_set_vbus,
};
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] usb: musb: Populate new IO functions for tusb6010
Let's populate the new IO functions for tusb6010 but not use
them yet.
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/usb/musb/tusb6010.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index 2daa779..996ea21 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -126,6 +126,41 @@ static void tusb_wbus_quirk(struct musb *musb, int enabled)
}
}
+static u32 tusb_fifo_offset(u8 epnum)
+{
+ return 0x200 + (epnum * 0x20);
+}
+
+/*
+ * TUSB6010 doesn't allow 8-bit access; 16-bit access is the minimum.
+ */
+static u8 tusb_readb(const void __iomem *addr, unsigned offset)
+{
+ u16 tmp;
+ u8 val;
+
+ tmp = __raw_readw(addr + (offset ~1));
+ if (offset 1)
+ val = (tmp 8);
+ else
+ val = tmp 0xff;
+
+ return val;
+}
+
+static void tusb_writeb(void __iomem *addr, unsigned offset, u8 data)
+{
+ u16 tmp;
+
+ tmp = __raw_readw(addr + (offset ~1));
+ if (offset 1)
+ tmp = (data 8) | (tmp 0xff);
+ else
+ tmp = (tmp 0xff00) | data;
+
+ __raw_writew(tmp, addr + (offset ~1));
+}
+
/*
* TUSB 6010 may use a parallel bus that doesn't support byte ops;
* so both loading and unloading FIFOs need explicit byte counts.
@@ -1135,9 +1170,15 @@ static int tusb_musb_exit(struct musb *musb)
}
static const struct musb_platform_ops tusb_ops = {
+ .quirks = MUSB_IN_TUSB,
.init = tusb_musb_init,
.exit = tusb_musb_exit,
+ .fifo_offset= tusb_fifo_offset,
+ .readb = tusb_readb,
+ .writeb = tusb_writeb,
+ .read_fifo = musb_read_fifo,
+ .write_fifo = musb_write_fifo,
.enable = tusb_musb_enable,
.disable= tusb_musb_disable,
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] usb: musb: Change to use new IO access
Change to use new IO access. This allows us to build in multiple
MUSB glue layers.
Cc: Fabio Baltieri fabio.balti...@linaro.org
Cc: Lee Jones lee.jo...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/usb/musb/am35x.c | 3 +-
drivers/usb/musb/blackfin.c | 8 +--
drivers/usb/musb/musb_core.c | 140 ++-
drivers/usb/musb/musb_io.h | 88 +++
drivers/usb/musb/musb_regs.h | 12
drivers/usb/musb/tusb6010.c | 8 +--
drivers/usb/musb/ux500_dma.c | 4 +-
7 files changed, 143 insertions(+), 120 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index a2735df..13d1d77 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -408,7 +408,7 @@ static int am35x_musb_exit(struct musb *musb)
}
/* AM35x supports only 32bit read operation */
-void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+static void am35x_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
{
void __iomem *fifo = hw_ep-fifo;
u32 val;
@@ -441,6 +441,7 @@ static const struct musb_platform_ops am35x_ops = {
.init = am35x_musb_init,
.exit = am35x_musb_exit,
+ .read_fifo = am35x_read_fifo,
.enable = am35x_musb_enable,
.disable= am35x_musb_disable,
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 8b5ad57..c55fcfd 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -71,7 +71,7 @@ static void binf_writel(void __iomem *addr, unsigned offset,
u32 data)
/*
* Load an endpoint's FIFO
*/
-void musb_write_fifo(struct musb_hw_ep *hw_ep, u16 len, const u8 *src)
+static void bfin_write_fifo(struct musb_hw_ep *hw_ep, u16 len, const u8 *src)
{
struct musb *musb = hw_ep-musb;
void __iomem *fifo = hw_ep-fifo;
@@ -135,7 +135,7 @@ void musb_write_fifo(struct musb_hw_ep *hw_ep, u16 len,
const u8 *src)
/*
* Unload an endpoint's FIFO
*/
-void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+static void bfin_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
{
struct musb *musb = hw_ep-musb;
void __iomem *fifo = hw_ep-fifo;
@@ -474,8 +474,8 @@ static const struct musb_platform_ops bfin_ops = {
.writew = bfin_writew,
.readl = bfin_readl,
.writel = bfin_writel,
- .read_fifo = musb_read_fifo,
- .write_fifo = musb_write_fifo,
+ .read_fifo = bfin_read_fifo,
+ .write_fifo = bfin_write_fifo,
.enable = bfin_musb_enable,
.disable= bfin_musb_disable,
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index b841ee0..2fbe149 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -224,12 +224,46 @@ static struct usb_phy_io_ops musb_ulpi_access = {
/*-*/
-#if !defined(CONFIG_USB_MUSB_TUSB6010) !defined(CONFIG_USB_MUSB_BLACKFIN)
+static u32 musb_default_fifo_offset(u8 epnum)
+{
+ return 0x20 + (epnum * 4);
+}
+
+static u8 musb_default_readb(const void __iomem *addr, unsigned offset)
+{
+ return __raw_readb(addr + offset);
+}
+
+static void musb_default_writeb(void __iomem *addr, unsigned offset, u8 data)
+{
+ __raw_writeb(data, addr + offset);
+}
+
+static u16 musb_default_readw(const void __iomem *addr, unsigned offset)
+{
+ return __raw_readw(addr + offset);
+}
+
+static void musb_default_writew(void __iomem *addr, unsigned offset, u16 data)
+{
+ __raw_writew(data, addr + offset);
+}
+
+static u32 musb_default_readl(const void __iomem *addr, unsigned offset)
+{
+ return __raw_readl(addr + offset);
+}
+
+static void musb_default_writel(void __iomem *addr, unsigned offset, u32 data)
+{
+ __raw_writel(data, addr + offset);
+}
/*
* Load an endpoint's FIFO
*/
-void musb_write_fifo(struct musb_hw_ep *hw_ep, u16 len, const u8 *src)
+static void musb_default_write_fifo(struct musb_hw_ep *hw_ep, u16 len,
+ const u8 *src)
{
struct musb *musb = hw_ep-musb;
void __iomem *fifo = hw_ep-fifo;
@@ -270,11 +304,10 @@ void musb_write_fifo(struct musb_hw_ep *hw_ep, u16 len,
const u8 *src)
}
}
-#if !defined(CONFIG_USB_MUSB_AM35X)
/*
* Unload an endpoint's FIFO
*/
-void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+static void musb_default_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
{
struct musb *musb = hw_ep-musb;
void __iomem *fifo = hw_ep-fifo;
@@ -312,10 +345,40 @@ void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8
*dst)
ioread8_rep(fifo, dst, len);
}
}
-#endif
-#endif /* normal PIO */
+/*
+ * Old style IO functions
+ */
+u8 (*musb_readb)(const
[PATCH 3/8] usb: musb: Populate new IO functions for blackfin
Populate new IO functions for blackfin
Cc: Bryan Wu coolo...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/usb/musb/blackfin.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index ac4422b..8b5ad57 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -33,6 +33,41 @@ struct bfin_glue {
};
#define glue_to_musb(g)platform_get_drvdata(g-musb)
+static u32 bfin_fifo_offset(u8 epnum)
+{
+ return USB_OFFSET(USB_EP0_FIFO) + (epnum * 8);
+}
+
+static u8 bfin_readb(const void __iomem *addr, unsigned offset)
+{
+ return (u8)(bfin_read16(addr + offset));
+}
+
+static u16 bfin_readw(const void __iomem *addr, unsigned offset)
+{
+ return bfin_read16(addr + offset);
+}
+
+static u32 bfin_readl(const void __iomem *addr, unsigned offset)
+{
+ return (u32)(bfin_read16(addr + offset));
+}
+
+static void bfin_writeb(void __iomem *addr, unsigned offset, u8 data)
+{
+ bfin_write16(addr + offset, (u16)data);
+}
+
+static void bfin_writew(void __iomem *addr, unsigned offset, u16 data)
+{
+ bfin_write16(addr + offset, data);
+}
+
+static void binf_writel(void __iomem *addr, unsigned offset, u32 data)
+{
+ bfin_write16(addr + offset, (u16)data);
+}
+
/*
* Load an endpoint's FIFO
*/
@@ -433,6 +468,14 @@ static const struct musb_platform_ops bfin_ops = {
.init = bfin_musb_init,
.exit = bfin_musb_exit,
+ .readb = bfin_readb,
+ .writeb = bfin_writeb,
+ .readw = bfin_readw,
+ .writew = bfin_writew,
+ .readl = bfin_readl,
+ .writel = bfin_writel,
+ .read_fifo = musb_read_fifo,
+ .write_fifo = musb_write_fifo,
.enable = bfin_musb_enable,
.disable= bfin_musb_disable,
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ASoC: tlv320aic31xx: Fix off by one error in the loop stucture.
On Mon, Nov 24, 2014 at 08:37:12PM +0200, Jyri Sarha wrote: Fix off by one read beyond the end of a table. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
On Mon, Nov 24, 2014 at 11:08:48AM -0800, Kevin Hilman wrote: On Sat, Nov 22, 2014 at 11:47 AM, Alexander Kochetkov al.koc...@gmail.com wrote: In a multimaster environment, after IP software reset, BB-bit value doesn't correspond to the current bus state. It may happen what BB-bit will be 0, while the bus is busy due to another I2C master activity. Any transfer started when BB=0 and bus is busy wouldn't be completed by IP and results in controller timeout. More over, in some cases IP could interrupt another master's transfer and corrupt data on wire. The commit implement method allowing to prevent IP from entering into controller timeout state and from data corruption state. The one drawback is the need to wait for 10ms before the first transfer. Tested on Beagleboard XM C. Tested on BBB and AM437x Starter Kit by Felipe Balbi. Signed-off-by: Alexander Kochetkov al.koc...@gmail.com Tested-by: Felipe Balbi ba...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com This patch recently hit linux-next (as commit 903c3859f77f) and boot breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards was bisected down to this commit. Kevin [1] http://status.armcloud.us/boot/?next-20141124omap btw, based on Kevin's boot test, only OMAP3530 is failing. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
Hi,
On Fri, Nov 21, 2014 at 01:28:43AM +0400, Alexander Kochetkov wrote:
In a multimaster environment, after IP software reset, BB-bit value doesn't
correspond to the current bus state. It may happen what BB-bit will be 0,
while the bus is busy due to another I2C master activity.
Any transfer started when BB=0 and bus is busy wouldn't be completed by IP
and results in controller timeout. More over, in some cases IP could
interrupt another master's transfer and corrupt data on wire.
The commit implement method allowing to prevent IP from entering into
controller timeout state and from data corruption state.
The one drawback is the need to wait for 10ms before the first transfer.
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
we have a report from Kevin Hilman that this commit breaks OMAP3530, see
[1]
[1]
http://storage.armcloud.us/kernel-ci/next/next-20141124/arm-omap2plus_defconfig/boot-omap3-overo-tobi.log
---
drivers/i2c/busses/i2c-omap.c | 103
+
1 file changed, 103 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a021733..3ffb9c0 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -58,6 +58,9 @@
/* timeout for pm runtime autosuspend */
#define OMAP_I2C_PM_TIMEOUT 1000/* ms */
+/* timeout for making decision on bus free status */
+#define OMAP_I2C_BUS_FREE_TIMEOUT (msecs_to_jiffies(10))
+
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
enum {
OMAP_I2C_REV_REG = 0,
@@ -210,6 +213,9 @@ struct omap_i2c_dev {
*/
u32 rev;
unsignedb_hw:1; /* bad h/w fixes */
+ unsignedbb_valid:1; /* true when BB-bit reflects
+ * the I2C bus state
+ */
unsignedreceiver:1; /* true when we're in receiver
mode */
u16 iestate;/* Saved interrupt register */
u16 pscstate;
@@ -336,7 +342,10 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
/* SYSC register is cleared by the reset; rewrite it */
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, sysc);
+ /* Schedule I2C-bus monitoring on the next transfer */
+ dev-bb_valid = 0;
}
+
return 0;
}
@@ -449,6 +458,11 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev-scllstate = scll;
dev-sclhstate = sclh;
+ if (dev-rev OMAP_I2C_OMAP1_REV_2) {
+ /* Not implemented */
+ dev-bb_valid = 1;
+ }
+
__omap_i2c_init(dev);
return 0;
@@ -473,6 +487,91 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
return 0;
}
+/*
+ * Wait while BB-bit doesn't reflect the I2C bus state
+ *
+ * In a multimaster environment, after IP software reset, BB-bit value
doesn't
+ * correspond to the current bus state. It may happen what BB-bit will be 0,
+ * while the bus is busy due to another I2C master activity.
+ * Here are BB-bit values after reset:
+ * SDA SCL BB NOTES
+ * 0 00 1, 2
+ * 1 00 1, 2
+ * 0 11
+ * 1 10 3
+ * Later, if IP detect SDA=0 and SCL=1 (ACK) or SDA 1-0 while SCL=1 (START)
+ * combinations on the bus, it set BB-bit to 1.
+ * If IP detect SDA 0-1 while SCL=1 (STOP) combination on the bus,
+ * it set BB-bit to 0 and BF to 1.
+ * BB and BF bits correctly tracks the bus state while IP is suspended
+ * BB bit became valid on the next FCLK clock after CON_EN bit set
+ *
+ * NOTES:
+ * 1. Any transfer started when BB=0 and bus is busy wouldn't be
+ *completed by IP and results in controller timeout.
+ * 2. Any transfer started when BB=0 and SCL=0 results in IP
+ *starting to drive SDA low. In that case IP corrupt data
+ *on the bus.
+ * 3. Any transfer started in the middle of another master's transfer
+ *results in unpredictable results and data corruption
+ */
+static int omap_i2c_wait_for_bb_valid(struct omap_i2c_dev *dev)
+{
+ unsigned long bus_free_timeout = 0;
+ unsigned long timeout;
+ int bus_free = 0;
+ u16 stat, systest;
+
+ if (dev-bb_valid)
+ return 0;
+
+ timeout = jiffies + OMAP_I2C_TIMEOUT;
+ while (1) {
+ stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ /*
+ * We will see BB or BF event in a case IP had detected any
+ * activity on the I2C bus. Now IP correctly tracks the bus
+ * state. BB-bit value is valid.
+ */
+ if (stat (OMAP_I2C_STAT_BB | OMAP_I2C_STAT_BF))
+ break
Re: [PATCH 4/8] usb: musb: Change to use new IO access
On Mon, Nov 24, 2014 at 11:05:02AM -0800, Tony Lindgren wrote: @@ -312,10 +345,40 @@ void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst) ioread8_rep(fifo, dst, len); } } -#endif -#endif /* normal PIO */ +/* + * Old style IO functions + */ +u8 (*musb_readb)(const void __iomem *addr, unsigned offset); +EXPORT_SYMBOL(musb_readb); + +void (*musb_writeb)(void __iomem *addr, unsigned offset, u8 data); +EXPORT_SYMBOL(musb_writeb); +u16 (*musb_readw)(const void __iomem *addr, unsigned offset); +EXPORT_SYMBOL(musb_readw); + +void (*musb_writew)(void __iomem *addr, unsigned offset, u16 data); +EXPORT_SYMBOL(musb_writew); + +u32 (*musb_readl)(const void __iomem *addr, unsigned offset); +EXPORT_SYMBOL(musb_readl); + +void (*musb_writel)(void __iomem *addr, unsigned offset, u32 data); +EXPORT_SYMBOL(musb_writel); let's make all these _GPL() -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
On Mon, Nov 24, 2014 at 01:10:23PM -0600, Felipe Balbi wrote: On Mon, Nov 24, 2014 at 11:08:48AM -0800, Kevin Hilman wrote: On Sat, Nov 22, 2014 at 11:47 AM, Alexander Kochetkov al.koc...@gmail.com wrote: In a multimaster environment, after IP software reset, BB-bit value doesn't correspond to the current bus state. It may happen what BB-bit will be 0, while the bus is busy due to another I2C master activity. Any transfer started when BB=0 and bus is busy wouldn't be completed by IP and results in controller timeout. More over, in some cases IP could interrupt another master's transfer and corrupt data on wire. The commit implement method allowing to prevent IP from entering into controller timeout state and from data corruption state. The one drawback is the need to wait for 10ms before the first transfer. Tested on Beagleboard XM C. Tested on BBB and AM437x Starter Kit by Felipe Balbi. Signed-off-by: Alexander Kochetkov al.koc...@gmail.com Tested-by: Felipe Balbi ba...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com This patch recently hit linux-next (as commit 903c3859f77f) and boot breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards was bisected down to this commit. Kevin [1] http://status.armcloud.us/boot/?next-20141124omap btw, based on Kevin's boot test, only OMAP3530 is failing. OK, giving Alexander some time for a fix. If it can't be found, I'll revert this patch. Thanks! signature.asc Description: Digital signature
[PATCH 0/8] Allow multiple MUSB glue layers to be built in
Hi all, I noticed MUSB did not work for me as loadable modules and it was because of the iffdeffery that breaks things with multiple glue layers enabled as loadable modules. I've set up function pointers for the PIO functions that now allow building in multiple glue layers as modules or built-in. Note that this series still does not sort out the DMA related issues, I have a series in works for that too. But that will take some more debugging. So far this has been tested to work on omap3, am335x and tusb6010. Regards, Tony Tony Lindgren (8): usb: musb: Add function pointers for IO access functions usb: musb: Populate new IO functions for tusb6010 usb: musb: Populate new IO functions for blackfin usb: musb: Change to use new IO access usb: musb: Change end point selection to use new IO access usb: musb: Pass fifo_mode in platform data usb: musb: Allow multiple glue layers to be built in usb: musb: Use IS_ENABLED for tusb6010 drivers/usb/musb/Kconfig | 5 +- drivers/usb/musb/am35x.c | 4 +- drivers/usb/musb/blackfin.c | 48 ++- drivers/usb/musb/da8xx.c | 2 + drivers/usb/musb/jz4740.c| 2 + drivers/usb/musb/musb_core.c | 199 --- drivers/usb/musb/musb_core.h | 86 ++- drivers/usb/musb/musb_dsps.c | 1 + drivers/usb/musb/musb_io.h | 106 ++- drivers/usb/musb/musb_regs.h | 26 -- drivers/usb/musb/musbhsdma.c | 7 +- drivers/usb/musb/tusb6010.c | 58 - drivers/usb/musb/ux500.c | 2 + drivers/usb/musb/ux500_dma.c | 4 +- 14 files changed, 356 insertions(+), 194 deletions(-) -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] usb: musb: Add function pointers for IO access functions
MUSB currently breaks badly if we try to build in support
for multiple platforms. This also happens if done as loadable
modules, which is not nice for distros.
Let's fix the issue by adding new struct musb_io for the IO
access functions that the platform code can populate. Note
that we don't want to use the current ops as that's really
platform_data and and set as a const.
This should allow eventually adding function pointers also
for the DMA code to struct musb_io, but that's a whole
different set of patches. For now, let's just fix the PIO
access.
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/usb/musb/musb_core.h | 40
drivers/usb/musb/musb_io.h | 18 ++
2 files changed, 58 insertions(+)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 414e57a..7c7f38c 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -173,8 +173,25 @@ enum musb_g_ep0_state {
/ TYPES */
+struct musb_io;
+
/**
* struct musb_platform_ops - Operations passed to musb_core by HW glue layer
+ * @quirks:flags for platform specific quirks
+ * @enable:enable device
+ * @disable: disable device
+ * @ep_offset: returns the end point offset
+ * @ep_select: selects the specified end point
+ * @fifo_mode: sets the fifo mode
+ * @fifo_offset: returns the fifo offset
+ * @readb: read 8 bits
+ * @writeb:write 8 bits
+ * @readw: read 16 bits
+ * @writew:write 16 bits
+ * @readl: read 32 bits
+ * @writel:write 32 bits
+ * @read_fifo: reads the fifo
+ * @write_fifo:writes to fifo
* @init: turns on clocks, sets up platform-specific registers, etc
* @exit: undoes @init
* @set_mode: forcefully changes operating mode
@@ -184,12 +201,34 @@ enum musb_g_ep0_state {
* @adjust_channel_params: pre check for standard dma channel_program func
*/
struct musb_platform_ops {
+
+#define MUSB_DMA_UX500 BIT(6)
+#define MUSB_DMA_CPPI41BIT(5)
+#define MUSB_DMA_CPPI BIT(4)
+#define MUSB_DMA_TUSB_OMAP BIT(3)
+#define MUSB_DMA_INVENTRA BIT(2)
+#define MUSB_IN_TUSB BIT(1)
+#define MUSB_INDEXED_EPBIT(0)
+ u32 quirks;
+
int (*init)(struct musb *musb);
int (*exit)(struct musb *musb);
void(*enable)(struct musb *musb);
void(*disable)(struct musb *musb);
+ u32 (*ep_offset)(u8 epnum, u16 offset);
+ void(*ep_select)(void __iomem *mbase, u8 epnum);
+ u16 fifo_mode;
+ u32 (*fifo_offset)(u8 epnum);
+ u8 (*readb)(const void __iomem *addr, unsigned offset);
+ void(*writeb)(void __iomem *addr, unsigned offset, u8 data);
+ u16 (*readw)(const void __iomem *addr, unsigned offset);
+ void(*writew)(void __iomem *addr, unsigned offset, u16 data);
+ u32 (*readl)(const void __iomem *addr, unsigned offset);
+ void(*writel)(void __iomem *addr, unsigned offset, u32 data);
+ void(*read_fifo)(struct musb_hw_ep *hw_ep, u16 len, u8 *buf);
+ void(*write_fifo)(struct musb_hw_ep *hw_ep, u16 len, const u8 *buf);
int (*set_mode)(struct musb *musb, u8 mode);
void(*try_idle)(struct musb *musb, unsigned long timeout);
int (*reset)(struct musb *musb);
@@ -292,6 +331,7 @@ struct musb {
/* device lock */
spinlock_t lock;
+ struct musb_io io;
const struct musb_platform_ops *ops;
struct musb_context_registers context;
diff --git a/drivers/usb/musb/musb_io.h b/drivers/usb/musb/musb_io.h
index eebeed7..46c01c8 100644
--- a/drivers/usb/musb/musb_io.h
+++ b/drivers/usb/musb/musb_io.h
@@ -37,6 +37,24 @@
#include linux/io.h
+/**
+ * struct musb_io - IO functions for MUSB
+ * @quirks:platform specific flags
+ * @ep_offset: platform specific function to get end point offset
+ * @ep_select: platform specific function to select end point
+ * @fifo_offset: platform specific function to get fifo offset
+ * @read_fifo: platform specific function to read fifo
+ * @write_fifo:platform specific function to write fifo
+ */
+struct musb_io {
+ u32 quirks;
+ u32 (*ep_offset)(u8 epnum, u16 offset);
+ void(*ep_select)(void __iomem *mbase, u8 epnum);
+ u32 (*fifo_offset)(u8 epnum);
+ void(*read_fifo)(struct musb_hw_ep *hw_ep, u16 len, u8 *buf);
+ void(*write_fifo)(struct musb_hw_ep *hw_ep, u16 len, const u8 *buf);
+};
+
#ifndef CONFIG_BLACKFIN
/* NOTE: these offsets are all in bytes */
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] usb: musb: Allow multiple glue layers to be built in
There's no reason any longer to keep it as a choice now that the IO access has been fixed. Signed-off-by: Tony Lindgren t...@atomide.com --- drivers/usb/musb/Kconfig | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 06cc5d6..9d68372 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -58,8 +58,7 @@ config USB_MUSB_DUAL_ROLE endchoice -choice - prompt Platform Glue Layer +comment Platform Glue Layer config USB_MUSB_DAVINCI tristate DaVinci @@ -101,8 +100,6 @@ config USB_MUSB_JZ4740 depends on USB_MUSB_GADGET depends on USB_OTG_BLACKLIST_HUB -endchoice - config USB_MUSB_AM335X_CHILD tristate -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
On Sat, Nov 22, 2014 at 11:47 AM, Alexander Kochetkov al.koc...@gmail.com wrote: In a multimaster environment, after IP software reset, BB-bit value doesn't correspond to the current bus state. It may happen what BB-bit will be 0, while the bus is busy due to another I2C master activity. Any transfer started when BB=0 and bus is busy wouldn't be completed by IP and results in controller timeout. More over, in some cases IP could interrupt another master's transfer and corrupt data on wire. The commit implement method allowing to prevent IP from entering into controller timeout state and from data corruption state. The one drawback is the need to wait for 10ms before the first transfer. Tested on Beagleboard XM C. Tested on BBB and AM437x Starter Kit by Felipe Balbi. Signed-off-by: Alexander Kochetkov al.koc...@gmail.com Tested-by: Felipe Balbi ba...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com This patch recently hit linux-next (as commit 903c3859f77f) and boot breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards was bisected down to this commit. Kevin [1] http://status.armcloud.us/boot/?next-20141124omap -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
On Sun, Nov 23, 2014 at 04:18:40PM +0300, Alexander Kochetkov wrote: 23 нояб. 2014 г., в 7:43, Felipe Balbi ba...@ti.com написал(а): maybe there was a typo? I tested on v3.18-rc3 :-) I do my tests on kernel from angstrom with almost all i2c-omap patches backported from linux/master. Then I rebased them to wrong (old) kernel version and posted to the list. Angstrom kernel is from meta-ti layer. It's the same kernel as for arago. http://arago-project.org/wiki/index.php/Main_Page I would really like to switch to the recent kernel, but I don't know how good codec engine (CE) is supported on it. Initially all ti drivers for codec engine was done for 2.6.x kernels and later some of them was ported for 3.2.x. Felipe, do you know how CE is supported on v3.18-rc3? what's CE ? -- balbi signature.asc Description: Digital signature
Re: v3.18-rc1: n900 battery discharged down to 2.97V
On Monday 24 November 2014 19:31:30 Pavel Machek wrote: Hi! I left the machine on usb-networking for extended period of time. Unfortunately, Xfce screensaver kept screen busy, and kernel failed to kill the machine. At the end, hardware protections worked (I guess), but result is battery discharged down to 2.97V. Best regards, Pavel So you need some program which will monitor battery status and when battery status is empty it should turn of device. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
* Wolfram Sang w...@the-dreams.de [141124 11:14]: On Mon, Nov 24, 2014 at 01:10:23PM -0600, Felipe Balbi wrote: On Mon, Nov 24, 2014 at 11:08:48AM -0800, Kevin Hilman wrote: On Sat, Nov 22, 2014 at 11:47 AM, Alexander Kochetkov al.koc...@gmail.com wrote: In a multimaster environment, after IP software reset, BB-bit value doesn't correspond to the current bus state. It may happen what BB-bit will be 0, while the bus is busy due to another I2C master activity. Any transfer started when BB=0 and bus is busy wouldn't be completed by IP and results in controller timeout. More over, in some cases IP could interrupt another master's transfer and corrupt data on wire. The commit implement method allowing to prevent IP from entering into controller timeout state and from data corruption state. The one drawback is the need to wait for 10ms before the first transfer. Tested on Beagleboard XM C. Tested on BBB and AM437x Starter Kit by Felipe Balbi. Signed-off-by: Alexander Kochetkov al.koc...@gmail.com Tested-by: Felipe Balbi ba...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com This patch recently hit linux-next (as commit 903c3859f77f) and boot breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards was bisected down to this commit. Kevin [1] http://status.armcloud.us/boot/?next-20141124omap btw, based on Kevin's boot test, only OMAP3530 is failing. OK, giving Alexander some time for a fix. If it can't be found, I'll revert this patch. Thanks! I can confirm reverting it fixes things for me as well thanks. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] usb: musb: Change to use new IO access
* Felipe Balbi ba...@ti.com [141124 11:13]: On Mon, Nov 24, 2014 at 11:05:02AM -0800, Tony Lindgren wrote: @@ -312,10 +345,40 @@ void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst) ioread8_rep(fifo, dst, len); } } -#endif -#endif /* normal PIO */ +/* + * Old style IO functions + */ +u8 (*musb_readb)(const void __iomem *addr, unsigned offset); +EXPORT_SYMBOL(musb_readb); + +void (*musb_writeb)(void __iomem *addr, unsigned offset, u8 data); +EXPORT_SYMBOL(musb_writeb); +u16 (*musb_readw)(const void __iomem *addr, unsigned offset); +EXPORT_SYMBOL(musb_readw); + +void (*musb_writew)(void __iomem *addr, unsigned offset, u16 data); +EXPORT_SYMBOL(musb_writew); + +u32 (*musb_readl)(const void __iomem *addr, unsigned offset); +EXPORT_SYMBOL(musb_readl); + +void (*musb_writel)(void __iomem *addr, unsigned offset, u32 data); +EXPORT_SYMBOL(musb_writel); let's make all these _GPL() Sure. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
24 нояб. 2014 г., в 22:08, Kevin Hilman khil...@kernel.org написал(а): This patch recently hit linux-next (as commit 903c3859f77f) and boot breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards was bisected down to this commit. Kevin [1] http://status.armcloud.us/boot/?next-20141124omap Could someone advice with debugging on OMAP3530? I'd like to apply one one more commit to see events during boot and see actual signals on wire (during of timeout)? Otherwise, commit must dropped (or rewritten such way it is disabled by default). 24 нояб. 2014 г., в 22:13, Wolfram Sang w...@the-dreams.de написал(а): OK, giving Alexander some time for a fix. If it can't be found, I'll revert this patch. Thanks! What deadline? Alexander. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
* Alexander Kochetkov al.koc...@gmail.com [141124 11:41]: 24 нояб. 2014 г., в 22:08, Kevin Hilman khil...@kernel.org написал(а): This patch recently hit linux-next (as commit 903c3859f77f) and boot breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards was bisected down to this commit. Kevin [1] http://status.armcloud.us/boot/?next-20141124omap Could someone advice with debugging on OMAP3530? Just try to boot it with your patch? :) I'd like to apply one one more commit to see events during boot and see actual signals on wire (during of timeout)? If you post a patch, I can test boot with it. Looks like the failing ones have i2c rev3.3 on 34xx vs rev4.4 on 36xx. But the test function should not loop forever in any case I take? So I doubt we just want to change the test for for a higher rev number for OMAP_I2C_REV_ON_3430_3530. Otherwise, commit must dropped (or rewritten such way it is disabled by default). 24 нояб. 2014 г., в 22:13, Wolfram Sang w...@the-dreams.de написал(а): OK, giving Alexander some time for a fix. If it can't be found, I'll revert this patch. Thanks! What deadline? I'd say by Tuesday as we have multiple automated test systems failing as soon as people update their trees. And when they are failing, we may miss other breakage happening in linux next. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
Guys, I really sorry for that :( Just try to boot it with your patch? :) Yes, may be two-three times (max). Something (u-boot, may be) leave the bus in the wrong state. Really strange. But the test function should not loop forever in any case I take? It doesn't loop forever. It finish with message: [3.046691] omap_i2c 4807.i2c: timeout waiting for bus ready So I doubt we just want to change the test for for a higher rev number for OMAP_I2C_REV_ON_3430_3530. Yes, I'll do it within 15 minutes. And later, if it possible, I'd try to see what happens. Alexander. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: i2c: don't check bus state IP rev3.3 and earlier
Commit 903c3859f77f9b0aace551da03267ef7a211dbc4 (i2c: omap: implement
workaround for handling invalid BB-bit values) introduce the error result
in boot test fault on OMAP3530 boards
The patch fix the error (disable i2c bus test for OMAP3530).
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
Fixes: 903c3859f77f9b0aace551da03267ef7a211dbc4
---
drivers/i2c/busses/i2c-omap.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5d92d0e..4563200 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -344,8 +344,10 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
/* SYSC register is cleared by the reset; rewrite it */
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, sysc);
- /* Schedule I2C-bus monitoring on the next transfer */
- dev-bb_valid = 0;
+ if (dev-rev OMAP_I2C_REV_ON_3430_3530) {
+ /* Schedule I2C-bus monitoring on the next transfer */
+ dev-bb_valid = 0;
+ }
}
return 0;
@@ -460,7 +462,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev-scllstate = scll;
dev-sclhstate = sclh;
- if (dev-rev OMAP_I2C_OMAP1_REV_2) {
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
/* Not implemented */
dev-bb_valid = 1;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
24 нояб. 2014 г., в 22:47, Tony Lindgren t...@atomide.com написал(а): I'd say by Tuesday as we have multiple automated test systems failing as soon as people update their trees. And when they are failing, we may miss other breakage happening in linux next. Fix: http://marc.info/?l=linux-i2cm=141686120720069w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: i2c: don't check bus state IP rev3.3 and earlier
* Alexander Kochetkov al.koc...@gmail.com [141124 12:35]:
Commit 903c3859f77f9b0aace551da03267ef7a211dbc4 (i2c: omap: implement
workaround for handling invalid BB-bit values) introduce the error result
in boot test fault on OMAP3530 boards
The patch fix the error (disable i2c bus test for OMAP3530).
Maybe add Reported-by: credit for Kevin Hilman here?
Other than that, this fixes the problem for me:
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
Fixes: 903c3859f77f9b0aace551da03267ef7a211dbc4
---
drivers/i2c/busses/i2c-omap.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5d92d0e..4563200 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -344,8 +344,10 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
/* SYSC register is cleared by the reset; rewrite it */
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, sysc);
- /* Schedule I2C-bus monitoring on the next transfer */
- dev-bb_valid = 0;
+ if (dev-rev OMAP_I2C_REV_ON_3430_3530) {
+ /* Schedule I2C-bus monitoring on the next transfer */
+ dev-bb_valid = 0;
+ }
}
return 0;
@@ -460,7 +462,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev-scllstate = scll;
dev-sclhstate = sclh;
- if (dev-rev OMAP_I2C_OMAP1_REV_2) {
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
/* Not implemented */
dev-bb_valid = 1;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] omap: i2c: don't check bus state IP rev3.3 and earlier
Commit 903c3859f77f9b0aace551da03267ef7a211dbc4 (i2c: omap: implement
workaround for handling invalid BB-bit values) introduce the error result
in boot test fault on OMAP3530 boards
The patch fix the error (disable i2c bus test for OMAP3530).
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
Fixes: 903c3859f77f9b0aace551da03267ef7a211dbc4
Reported-by: Kevin Hilman khil...@kernel.org
Tested-by: Tony Lindgren t...@atomide.com
---
drivers/i2c/busses/i2c-omap.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5d92d0e..4563200 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -344,8 +344,10 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
/* SYSC register is cleared by the reset; rewrite it */
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, sysc);
- /* Schedule I2C-bus monitoring on the next transfer */
- dev-bb_valid = 0;
+ if (dev-rev OMAP_I2C_REV_ON_3430_3530) {
+ /* Schedule I2C-bus monitoring on the next transfer */
+ dev-bb_valid = 0;
+ }
}
return 0;
@@ -460,7 +462,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev-scllstate = scll;
dev-sclhstate = sclh;
- if (dev-rev OMAP_I2C_OMAP1_REV_2) {
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
/* Not implemented */
dev-bb_valid = 1;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] mailbox/omap: adapt to the new mailbox framework
Hi Jassi,
On 11/24/2014 03:54 AM, Jassi Brar wrote:
On 4 November 2014 at 04:35, Suman Anna s-a...@ti.com wrote:
The OMAP mailbox driver and its existing clients (remoteproc
for OMAP4+) are adapted to use the generic mailbox framework.
The main changes for the adaptation are:
- The tasklet used for Tx is replaced with the state machine from
the generic mailbox framework. The workqueue used for processing
the received messages stays intact for minimizing the effects on
the OMAP mailbox clients.
- The existing exported client API, omap_mbox_get, omap_mbox_put and
omap_mbox_send_msg are deleted, as the framework provides equivalent
functionality. A OMAP-specific omap_mbox_request_channel is added
though to support non-DT way of requesting mailboxes.
- The OMAP mailbox driver is integrated with the mailbox framework
through the proper implementations of mbox_chan_ops, except for
.last_tx_done and .peek_data. The OMAP mailbox driver does not need
these ops, as it is completely interrupt driven.
- The OMAP mailbox driver uses a custom of_xlate controller ops that
allows phandles for the pargs specifier instead of indexing to avoid
any channel registration order dependencies.
- The new framework does not support multiple clients operating on a
single channel, so the reference counting logic is simplified.
- The remoteproc driver (current client) is adapted to use the new API.
The notifier callbacks used within this client is replaced with the
regular callbacks from the newer framework.
- The exported OMAP mailbox API are limited to omap_mbox_save_ctx,
omap_mbox_restore_ctx, omap_mbox_enable_irq omap_mbox_disable_irq,
with the signature modified to take in the new mbox_chan handle instead
of the OMAP specific omap_mbox handle. The first 2 will be removed when
the OMAP mailbox driver is adapted to runtime_pm. The other exported
API omap_mbox_request_channel will be removed once existing legacy
users are converted to DT.
Cc: Jassi Brar jassisinghb...@gmail.com
Cc: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Suman Anna s-a...@ti.com
---
v3-v4: No code changes, switched the example to use the DSP node instead of
WkupM3 in the bindings document minor commit description changes. Other
than
that, this is a repost of the driver adaptation patch [1] from the OMAP
Mailbox
framework adaptation series [2]. This patch is intended for the 3.19 merge
window,
all the dependent patches in [2] are merged as of 3.18-rc2. The DTS patch in
[2]
will be posted separately.
[1] http://marc.info/?l=linux-omapm=141038453917790w=2
[2] http://marc.info/?l=linux-omapm=141038447817775w=2
.../devicetree/bindings/mailbox/omap-mailbox.txt | 23 ++
drivers/mailbox/omap-mailbox.c | 346
-
drivers/remoteproc/omap_remoteproc.c | 51 +--
include/linux/omap-mailbox.h | 16 +-
4 files changed, 256 insertions(+), 180 deletions(-)
diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
index 48edc4b..d1a0433 100644
--- a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -43,6 +43,9 @@ Required properties:
device. The format is dependent on which interrupt
controller the OMAP device uses
- ti,hwmods: Name of the hwmod associated with the mailbox
+- #mbox-cells: Common mailbox binding property to identify the
number
+ of cells required for the mailbox specifier. Should
be
+ 1
- ti,mbox-num-users: Number of targets (processor devices) that the
mailbox
device can interrupt
- ti,mbox-num-fifos: Number of h/w fifo queues within the mailbox IP block
@@ -72,6 +75,18 @@ data that represent the following:
Cell #3 (usr_id) - mailbox user id for identifying the interrupt line
associated with generating a tx/rx fifo interrupt.
+Mailbox Users:
+==
+A device needing to communicate with a target processor device should
specify
+them using the common mailbox binding properties, mboxes and the optional
+mbox-names (please see
Documentation/devicetree/bindings/mailbox/mailbox.txt
+for details). Each value of the mboxes property should contain a phandle to
the
+mailbox controller device node and an args specifier that will be the
phandle to
+the intended sub-mailbox child node to be used for communication. The
equivalent
+mbox-names property value can be used to give a name to the communication
channel
+to be used by the client user.
+
+
Example:
@@ -81,6 +96,7 @@ mailbox: mailbox@4a0f4000 {
reg = 0x4a0f4000 0x200;
Re: [PATCH 5/8] usb: musb: Change end point selection to use new IO access
Hi Tony,
Thanks for the patch.
On Mon, Nov-24-2014 at 11:05:03 AM -0800, Tony Lindgren wrote:
This allows the endpoints to work when multiple MUSB glue
layers are built in.
Applied on top of 3.18-rc6 mainline and tested successfully on JZ4740.
Been able to use ethernet-over-usb to access the internet on
device. No issue as far as I'm concerned.
Acked-by: Apelete Seketeli apel...@seketeli.net
Cc: Fabio Baltieri fabio.balti...@linaro.org
Cc: Lee Jones lee.jo...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Apelete Seketeli apel...@seketeli.net
Cc: Lars-Peter Clausen l...@metafoo.de
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/usb/musb/am35x.c | 1 +
drivers/usb/musb/da8xx.c | 1 +
drivers/usb/musb/jz4740.c| 1 +
drivers/usb/musb/musb_core.c | 38 +-
drivers/usb/musb/musb_core.h | 37 +
drivers/usb/musb/musb_dsps.c | 1 +
drivers/usb/musb/musb_io.h | 2 ++
drivers/usb/musb/musb_regs.h | 11 ---
drivers/usb/musb/musbhsdma.c | 7 ---
drivers/usb/musb/tusb6010.c | 13 +
drivers/usb/musb/ux500.c | 1 +
11 files changed, 62 insertions(+), 51 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 13d1d77..1ea4a67 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -438,6 +438,7 @@ static void am35x_read_fifo(struct musb_hw_ep *hw_ep, u16
len, u8 *dst)
}
static const struct musb_platform_ops am35x_ops = {
+ .quirks = MUSB_INDEXED_EP,
.init = am35x_musb_init,
.exit = am35x_musb_exit,
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 058775e..c9079c8 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -458,6 +458,7 @@ static int da8xx_musb_exit(struct musb *musb)
}
static const struct musb_platform_ops da8xx_ops = {
+ .quirks = MUSB_INDEXED_EP,
.init = da8xx_musb_init,
.exit = da8xx_musb_exit,
diff --git a/drivers/usb/musb/jz4740.c b/drivers/usb/musb/jz4740.c
index d118729..40e9874 100644
--- a/drivers/usb/musb/jz4740.c
+++ b/drivers/usb/musb/jz4740.c
@@ -106,6 +106,7 @@ static int jz4740_musb_exit(struct musb *musb)
}
static const struct musb_platform_ops jz4740_musb_ops = {
+ .quirks = MUSB_INDEXED_EP,
.init = jz4740_musb_init,
.exit = jz4740_musb_exit,
};
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2fbe149..48ddc82 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -229,6 +229,27 @@ static u32 musb_default_fifo_offset(u8 epnum)
return 0x20 + (epnum * 4);
}
+/* flat mapping: each endpoint has its own i/o address */
+static void musb_flat_ep_select(void __iomem *mbase, u8 epnum)
+{
+}
+
+static u32 musb_flat_ep_offset(u8 epnum, u16 offset)
+{
+ return 0x100 + (0x10 * epnum) + offset;
+}
+
+/* indexed mapping: INDEX register controls register bank select */
+static void musb_indexed_ep_select(void __iomem *mbase, u8 epnum)
+{
+ musb_writeb(mbase, MUSB_INDEX, epnum);
+}
+
+static u32 musb_indexed_ep_offset(u8 epnum, u16 offset)
+{
+ return 0x10 + offset;
+}
+
static u8 musb_default_readb(const void __iomem *addr, unsigned offset)
{
return __raw_readb(addr + offset);
@@ -1534,7 +1555,7 @@ static int musb_core_init(u16 musb_type, struct musb
*musb)
}
#endif
- hw_ep-regs = MUSB_EP_OFFSET(i, 0) + mbase;
+ hw_ep-regs = musb-io.ep_offset(i, 0) + mbase;
hw_ep-target_regs = musb_read_target_reg_base(i, mbase);
hw_ep-rx_reinit = 1;
hw_ep-tx_reinit = 1;
@@ -2004,6 +2025,21 @@ musb_init_controller(struct device *dev, int nIrq,
void __iomem *ctrl)
if (musb-ops-quirks)
musb-io.quirks = musb-ops-quirks;
+ /* At least tusb6010 has it's own offsets.. */
+ if (musb-ops-ep_offset)
+ musb-io.ep_offset = musb-ops-ep_offset;
+ if (musb-ops-ep_select)
+ musb-io.ep_select = musb-ops-ep_select;
+
+ /* ..and some devices use indexed offset or flat offset */
+ if (musb-io.quirks MUSB_INDEXED_EP) {
+ musb-io.ep_offset = musb_indexed_ep_offset;
+ musb-io.ep_select = musb_indexed_ep_select;
+ } else {
+ musb-io.ep_offset = musb_flat_ep_offset;
+ musb-io.ep_select = musb_flat_ep_select;
+ }
+
if (musb-ops-fifo_offset)
musb-io.fifo_offset = musb-ops-fifo_offset;
else
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7c7f38c..02f62cb 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -124,41 +124,6 @@ enum musb_g_ep0_state {
#define OTG_TIME_A_AIDL_BDIS 200
Re: [PATCH 6/8] usb: musb: Pass fifo_mode in platform data
Hi Tony,
Thanks for this one too.
On Mon, Nov-24-2014 at 11:05:04 AM -0800, Tony Lindgren wrote:
This allows setting the correct fifo_mode when multiple
MUSB glue layers are built-in.
Applied on top of 3.18-rc6 mainline and tested successfully on JZ4740.
Been able to use ethernet-over-usb to access the internet on
device. No issue as far as I'm concerned.
Acked-by: Apelete Seketeli apel...@seketeli.net
Cc: Fabio Baltieri fabio.balti...@linaro.org
Cc: Lee Jones lee.jo...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Apelete Seketeli apel...@seketeli.net
Cc: Lars-Peter Clausen l...@metafoo.de
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/usb/musb/blackfin.c | 1 +
drivers/usb/musb/da8xx.c | 1 +
drivers/usb/musb/jz4740.c| 1 +
drivers/usb/musb/musb_core.c | 21 ++---
drivers/usb/musb/ux500.c | 1 +
5 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index c55fcfd..b8442b9 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -474,6 +474,7 @@ static const struct musb_platform_ops bfin_ops = {
.writew = bfin_writew,
.readl = bfin_readl,
.writel = bfin_writel,
+ .fifo_mode = 2,
.read_fifo = bfin_read_fifo,
.write_fifo = bfin_write_fifo,
.enable = bfin_musb_enable,
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index c9079c8..5f9b486 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -462,6 +462,7 @@ static const struct musb_platform_ops da8xx_ops = {
.init = da8xx_musb_init,
.exit = da8xx_musb_exit,
+ .fifo_mode = 2,
.enable = da8xx_musb_enable,
.disable= da8xx_musb_disable,
diff --git a/drivers/usb/musb/jz4740.c b/drivers/usb/musb/jz4740.c
index 40e9874..bb7b263 100644
--- a/drivers/usb/musb/jz4740.c
+++ b/drivers/usb/musb/jz4740.c
@@ -107,6 +107,7 @@ static int jz4740_musb_exit(struct musb *musb)
static const struct musb_platform_ops jz4740_musb_ops = {
.quirks = MUSB_INDEXED_EP,
+ .fifo_mode = 2,
.init = jz4740_musb_init,
.exit = jz4740_musb_exit,
};
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 48ddc82..0875365 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1116,21 +1116,7 @@ static void musb_shutdown(struct platform_device *pdev)
* We don't currently use dynamic fifo setup capability to do anything
* more than selecting one of a bunch of predefined configurations.
*/
-#if defined(CONFIG_USB_MUSB_TUSB6010)\
- || defined(CONFIG_USB_MUSB_TUSB6010_MODULE) \
- || defined(CONFIG_USB_MUSB_OMAP2PLUS) \
- || defined(CONFIG_USB_MUSB_OMAP2PLUS_MODULE)\
- || defined(CONFIG_USB_MUSB_AM35X) \
- || defined(CONFIG_USB_MUSB_AM35X_MODULE)\
- || defined(CONFIG_USB_MUSB_DSPS)\
- || defined(CONFIG_USB_MUSB_DSPS_MODULE)
-static ushort fifo_mode = 4;
-#elif defined(CONFIG_USB_MUSB_UX500) \
- || defined(CONFIG_USB_MUSB_UX500_MODULE)
-static ushort fifo_mode = 5;
-#else
-static ushort fifo_mode = 2;
-#endif
+static ushort fifo_mode;
/* modprobe ... fifo_mode=1 etc */
module_param(fifo_mode, ushort, 0);
@@ -2040,6 +2026,11 @@ musb_init_controller(struct device *dev, int nIrq,
void __iomem *ctrl)
musb-io.ep_select = musb_flat_ep_select;
}
+ if (musb-ops-fifo_mode)
+ fifo_mode = musb-ops-fifo_mode;
+ else
+ fifo_mode = 4;
+
if (musb-ops-fifo_offset)
musb-io.fifo_offset = musb-ops-fifo_offset;
else
diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c
index c170501..c372518 100644
--- a/drivers/usb/musb/ux500.c
+++ b/drivers/usb/musb/ux500.c
@@ -191,6 +191,7 @@ static const struct musb_platform_ops ux500_ops = {
.quirks = MUSB_INDEXED_EP,
.init = ux500_musb_init,
.exit = ux500_musb_exit,
+ .fifo_mode = 5,
.set_vbus = ux500_musb_set_vbus,
};
--
2.1.3
--
Apelete
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] usb: musb: Change end point selection to use new IO access
* Apelete Seketeli apel...@seketeli.net [141124 15:40]: Hi Tony, Thanks for the patch. On Mon, Nov-24-2014 at 11:05:03 AM -0800, Tony Lindgren wrote: This allows the endpoints to work when multiple MUSB glue layers are built in. Applied on top of 3.18-rc6 mainline and tested successfully on JZ4740. Been able to use ethernet-over-usb to access the internet on device. No issue as far as I'm concerned. Great that's good to hear and thanks for testing. Doing the DMA patches here right now.. For the DMA, I've set up JZ4740 to use the MUSB_DMA_INVENTRA option by default, is that OK or do you have some other DMA hardware on it? If MUSB_DMA_INVENTRA does not work, and you don't have other DMA hardware on it, we can pass MUSB_DMA_INVENTRA and leave the DMA function pointers empty, and then the driver will bail out during init unless the option for CONFIG_MUSB_PIO_ONLY is set. Just that I could not figure out if that's the one to use grepping the *_defconfig files. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
24 нояб. 2014 г., в 23:05, Alexander Kochetkov al.koc...@gmail.com написал(а): Something (u-boot, may be) leave the bus in the wrong state. Really strange. Actually something wrong with i2c-pullups on i2c.1 bus on fault boards. May be these are boards without pull-ups? All beagles doesn't have internal pull-ups on i2c.1 since u-boot 2011.x. Here is the bug in the u-boot related to beagle: http://git.denx.de/?p=u-boot.git;a=commit;h=04e2a13336f0e507ef416bbede3be92b79c46594 Yes, I made fix, but keep that in mind. For example one of the boards (omap3-beagle): http://status.armcloud.us/boot/omap3-beagle/job/next/kernel/next-20141124/defconfig/arm-omap2plus_defconfig/ http://status.armcloud.us/boot/omap3-beagle,legacy/job/next/kernel/next-20141124/defconfig/arm-omap2plus_defconfig/ http://status.armcloud.us/boot/omap3-beagle/job/next/kernel/next-20141124/defconfig/arm-multi_v7_defconfig/ has following warning message in the u-boot log: U-Boot 2014.07 (Aug 21 2014 - 11:03:05) OMAP3530-GP ES3.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz OMAP3 Beagle board + LPDDR/NAND Beagle Rev C1/C2/C3 Timed out in wait_for_event: status=1000 Check if pads/pull-ups of bus 1 are properly configured Also beagle schematic has following log entry for A3: 4. Added optional pullup resistors on I2C2_SCL and I2C_SDA into the layout. Is the fault beagle is pre A3 revision? I can't tell anything about second one board (omap3-overo-tobi), because I could not get it schematic. And how you have i2c.1 working without pull-ups I don't know. Alexander. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.18-rc6
Here are some basic OMAP test results for Linux v3.18-rc6. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.18-rc6/20141123170640/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm vmlinux object size (delta in bytes from test_v3.18-rc5 (fc14f9c1272f62c3e8d01300f52467c0d9af50f9)): text data bsstotal kernel -2000 -20 omap1_defconfig +1200 +12 omap1_defconfig_1510innovator_only -5200 -52 omap1_defconfig_5912osk_only +9640 +1840+9824 multi_v7_defconfig -116 -160 -132 omap2plus_defconfig -140 +240 -116 omap2plus_defconfig_2430sdp_only -116 -80 -124 omap2plus_defconfig_am33xx_only -116 -80 -124 omap2plus_defconfig_am43xx_only -116 -80 -124 omap2plus_defconfig_cpupm -116 -80 -124 omap2plus_defconfig_dra7xx_only -156 +320 -124 omap2plus_defconfig_n800_multi_omap2xxx -124 +240 -100 omap2plus_defconfig_n800_only_a -116 -80 -124 omap2plus_defconfig_no_pm -116 -80 -124 omap2plus_defconfig_omap2_4_only -116 -80 -124 omap2plus_defconfig_omap3_4_only -52 +240 -28 omap2plus_defconfig_omap5_only -1240 -48 -172 rmk_omap3430_ldp_allnoconfig -88 +240 -64 rmk_omap3430_ldp_oldconfig -1400 -32 -172 rmk_omap4430_sdp_allnoconfig +3984 -160+3968 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.18-rc5 (fc14f9c1272f62c3e8d01300f52467c0d9af50f9)) avail rsrvd high freed board kconfig 352k -352k .-4k am335xbonelt omap2plus_defconfig The big boot-time memory difference for am335xbonelt is bogus. Looks like during the v3.18-rc5 test run, that board actually booted a v3.18-rc1 kernel. Have to get a check for that into
Re: [RFC PATCH] ARM: DRA: hwmod: RTC: Add reset function for RTC
Hi Paul,
On Thursday 20 November 2014 10:26 PM, Paul Walmsley wrote:
On Thu, 20 Nov 2014, Lokesh Vutla wrote:
On Monday 17 November 2014 10:13 AM, Lokesh Vutla wrote:
RTC IP have kicker feature which prevents spurious writes to its registers.
In order to write into any of the RTC registers, KICK values has te be
written to KICK registers. Currently hwmod is updating the IDLEMODE in rtc
sysconfig register without writing into any kick register which is a noop.
When autoidle is allowed for rtc, interruts are not received until IDLEMODE
is set to SIDLE_SMART_WKUP.
Adding a reset function to unlock RTC registers so that IDLEMODE is
updated.
Ping..!!
Is this patch acceptable?
Lokesh
1. This looks like a fix. Is this intended to go in as a v3.18-rc patch,
or against v3.19? If so it would be very helpful for the maintainers if
you were to state that somewhere.
Yes. This is a fix, intended to go in 3.18-rc. Sorry should have
mentioned it.
2. Your patch unlocks the RTC registers, but never relocks it. This seems
to defeat the point of the spurious write protection. Shouldn't your
patch only unlock the RTC immediately before the hwmod code touches the
RTC registers, and then relock it immediately afterwards, per SPRUHZ6
section 23.4.3.3? If so then the .reset function pointer is the wrong
place for this; I would suggest adding some .lock and .unlock function
pointers that are to be called before and after any register write to the
IP block.
Yeah I agree with you.
Currently rtc driver unlocks these kick registers in probe and leaves it
unlocks for
further use.
But if hwmod does unlock and lock for every sysconfig write driver should also
implement unlock and lock for every rtc register write, which adds an extra
overhead.
I am not sure if some one writes into rtc registers other than hwmod and driver.
IMO we can leave it unlocked as the driver does.
3. Your macros don't mention DRA7xx specifically. Does this sequence
apply to some other TI chips, or just DRA7xx? Please document this in a
comment above the macros, and possibly change the name of the macros to
refer to DRA7XX.
This sequence applies to AM43xx and AM33xx also. So made it generic.
Ill document it.
Thanks and regards,
Lokesh
- Paul
Thanks and regards,
Lokesh
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.h | 1 +
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 1 +
arch/arm/mach-omap2/omap_hwmod_reset.c| 23 +++
3 files changed, 25 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.h
b/arch/arm/mach-omap2/omap_hwmod.h
index 512f809..3703f99 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -744,6 +744,7 @@ const char *omap_hwmod_get_main_clk(struct omap_hwmod
*oh);
*/
extern int omap_hwmod_aess_preprogram(struct omap_hwmod *oh);
+int omap_hwmod_rtc_unlock(struct omap_hwmod *oh);
/*
* Chip variant-specific hwmod init routines - XXX should be converted
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 5684f11..90e1df4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1584,6 +1584,7 @@ static struct omap_hwmod_class_sysconfig
dra7xx_rtcss_sysc = {
static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = {
.name = rtcss,
.sysc = dra7xx_rtcss_sysc,
+ .reset = omap_hwmod_rtc_unlock,
};
/* rtcss */
diff --git a/arch/arm/mach-omap2/omap_hwmod_reset.c
b/arch/arm/mach-omap2/omap_hwmod_reset.c
index 65e186c..b825a28 100644
--- a/arch/arm/mach-omap2/omap_hwmod_reset.c
+++ b/arch/arm/mach-omap2/omap_hwmod_reset.c
@@ -30,6 +30,12 @@
#include omap_hwmod.h
+#define RTC_KICK0_REG_OFFSET 0x6c
+#define RTC_KICK1_REG_OFFSET 0x70
+
+#define RTC_KICK0_VALUE0x83E70B13
+#define RTC_KICK1_VALUE0x95A4F1E0
+
/**
* omap_hwmod_aess_preprogram - enable AESS internal autogating
* @oh: struct omap_hwmod *
@@ -51,3 +57,20 @@ int omap_hwmod_aess_preprogram(struct omap_hwmod *oh)
return 0;
}
+
+/**
+ * omap_hwmod_rtc_unlock - Reset and unlock the Kicker mechanism.
+ * @oh: struct omap_hwmod *
+ *
+ * RTC IP have kicker feature. This prevents spurious writes to its
registers.
+ * In order to write into any of the RTC registers, KICK values has te be
+ * written in respective KICK registers. This is needed for hwmod to write
into
+ * sysconfig register.
+ */
+int omap_hwmod_rtc_unlock(struct omap_hwmod *oh)
+{
+ omap_hwmod_write(RTC_KICK0_VALUE, oh, RTC_KICK0_REG_OFFSET);
+ omap_hwmod_write(RTC_KICK1_VALUE, oh, RTC_KICK1_REG_OFFSET);
+
+ return 0;
+}
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
