Re: n900 audio: any ideas how to get headset speaker to work?
On Sunday 15 February 2015 11:21:52 Pavel Machek wrote: Hi! By default, output goes to loudspeaker (top right relative to keyboard). Any ideas how to switch it to the speaker on the left or wired headset? Because I suspect that echo cancelation is not going to be simple... Pavel I do not know but maybe this file could help: https://gitorious.org/community-ssu/policy-settings-rx51/source/dcb6429c12006dc9850cc942b7143358fe3fd330:rx51/etc/alsaped.conf There are definitions of alsa channels and settings for different profiles. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v3 1/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core
Hi Alan: thanks for comment it, and sorry that a little bit late for replying, 2015-02-12 23:18 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Thu, 12 Feb 2015, Mathias Nyman wrote: On 25.01.2015 10:13, Sneeker Yeh wrote: This issue is defined by a three-way race at disconnect, between 1) Class driver interrupt endpoint resheduling attempts if the ISR gave an ep error event due to device detach (it would try 3 times) 2) Disconnect interrupt on PORTSC_CSC, which is cleared by hub thread asynchronously 3) The hardware IP was configured in silicon with - DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1 - Synopsys IP version is 3.00a The IP will auto-suspend itself on device detach with some phy-specific interval after CSC is cleared by 2) If 2) and 3) complete before 1), the interrupts it expects will not be generated by the autosuspended IP, leading to a deadlock. Even later disconnection procedure would detect that corresponding urb is still in-progress and issue a ep stop command, auto-suspended IP still won't respond to that command. If the Synopsys IP provides a way to do it, it would be better to turn off the autosuspend feature entirely. Doesn't autosuspend violate the xHCI specification? it's an IP parameter that can't be turn off via any register . I guess Synopsis can insisted that xHCI specification doesn't explicitly state that hardware designer shouldn't do auto-suspend when device is attached, especially that definition of the auto-suspend is their own specific low power state. IIRC, this is point of view from Synopsis. I wonder maybe they just didn't have a good assumption when implementing auto-suspend, e.g. they shouldn't take PORTCSC clearing as a commitment that software has done all the device detach task, so that IP can go into suspend. it seems more reasonable to take slot-disabling as a commitment to a start of auto-suspend. anyway the errata would be disclosed recently, and Synopsis plan to fix it in their new silicon version IP. Old version IP has to live happily with some patch that can workaround this monster i think. Much appreciate, Sneeker So did I understand correctly that the class driver submits a new urb which is enqueued by xhci_urb_enqueue() before the hub thread notices the device is disconnected. Then hub thread clears CSC bit, controller suspends and the new urb is never given back? Doesn't the CSC bit and PORT_CONNECT bit show the device is disconnected when we enter xhci_enqueue_urb(), even it the hub thread doesn't know this yet? What if the device disconnects _after_ the new URB is enqueued? Would it make sense to check those bits in xhci_enqueue_urb, and just return error in the xhci_urb_enqueue() if device is not connected? Then there wouldn't be a need for any quirk at all. That wouldn't help URBs that were already enqueued when the disconnect occurred. Alan Stern -- 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: n900 audio: any ideas how to get headset speaker to work?
2015-02-15 11:21 GMT+01:00 Pavel Machek pa...@ucw.cz: Hi! By default, output goes to loudspeaker (top right relative to keyboard). Any ideas how to switch it to the speaker on the left or wired headset? Because I suspect that echo cancelation is not going to be simple... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html Hi, in case of direct alsa output (not PA), setup is pretty complex. Headphones referenced as line. All audio outputs are differential. Here are controls that affects volumes... global: PCM (volume) left/right DAC mux (below) -- DAC_L1/R1 passes sound to loudspeakers, line, (maybe others) -- DAC_L2/R2 passes sound to loudspeakers, NOT line, (maybe others) -- DAC_L3/R3 passes sound to NOT loudspeakers, line, (maybe others) if DAC_L1/R1 is chosen, you can hear lower volume on both outputs in compare to dedicated outputs (DAC_L2/R2, DAC_L3/R3), probabbly due to higher load of ADC loudspeakers: Speaker function (on) HP (unmute) HP DAC (volume) left HP Mixer DACL1 (below) right HP Mixer DACR1 (below) --unmute theese two, this will pass left channel sound to left channel output and vice versa left HP Mixer DACR1 (below) right HP Mixer DACL1 (below) --mute these two, this controls channel crosstalk ( amount of left channel sound going to right channel output and vice versa) line: line (unmute) line DAC (volume) jack function (headphone) TPA6130A2 Headphone (volume) left Line Mixer DACL1 (below) right Line Mixer DACR1 (below) --unmute theese two, this will pass left channel sound to left channel output and vice versa left Line Mixer DACR1 (below) right Line Mixer DACL1 (below) --mute these two, this controls channel crosstalk ( amount of left channel sound going to right channel output and vice versa) -- 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 1/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core
hi Mathias:
thanks for reviewing these patch,
and sorry for replying lately~
2015-02-12 21:50 GMT+08:00 Mathias Nyman mathias.ny...@intel.com:
On 25.01.2015 10:13, Sneeker Yeh wrote:
This issue is defined by a three-way race at disconnect, between
1) Class driver interrupt endpoint resheduling attempts if the ISR gave an ep
error event due to device detach (it would try 3 times)
2) Disconnect interrupt on PORTSC_CSC, which is cleared by hub thread
asynchronously
3) The hardware IP was configured in silicon with
- DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1
- Synopsys IP version is 3.00a
The IP will auto-suspend itself on device detach with some phy-specific
interval
after CSC is cleared by 2)
If 2) and 3) complete before 1), the interrupts it expects will not be
generated
by the autosuspended IP, leading to a deadlock. Even later disconnection
procedure would detect that corresponding urb is still in-progress and issue
a
ep stop command, auto-suspended IP still won't respond to that command.
So did I understand correctly that the class driver submits a new urb which
is enqueued by xhci_urb_enqueue() before the hub thread notices the device is
disconnected.
Then hub thread clears CSC bit, controller suspends and the new urb is never
given back?
yes.
Doesn't the CSC bit and PORT_CONNECT bit show the device is disconnected when
we enter
xhci_enqueue_urb(), even it the hub thread doesn't know this yet?
Would it make sense to check those bits in xhci_enqueue_urb, and just return
error
in the xhci_urb_enqueue() if device is not connected? Then there wouldn't be
a need for any quirk
at all.
ya I tried this before, it would work if i stop enqueue when i found
device detached,
but sometime it won't work when device might be detached just right
after i done enqueue, just like Alan mentioned.
If that doesn't work then this patch looks good in general. See comments below
this defect would result in this when device detached:
---
[ 99.603544] usb 4-1: USB disconnect, device number 2
[ 104.615254] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop
endpoint command.
[ 104.623362] xhci-hcd xhci-hcd.0.auto: Assuming host is dying, halting
host.
[ 104.653261] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000
microseconds.
[ 104.660584] xhci-hcd xhci-hcd.0.auto: Non-responsive xHCI host is not
halting.
[ 104.667817] xhci-hcd xhci-hcd.0.auto: Completing active URBs anyway.
[ 104.674198] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
--
As a result, when device detached, we desired to postpone PORTCSC clear
behind
disable slot. it's found that all executed ep command related to
disconnetion,
are executed before disable slot.
Signed-off-by: Sneeker Yeh sneeker@tw.fujitsu.com
---
drivers/usb/host/xhci-hub.c |4
drivers/usb/host/xhci.c | 29 +
drivers/usb/host/xhci.h | 24
3 files changed, 57 insertions(+)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index a7865c4..3b8f7fc 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -368,6 +368,10 @@ static void xhci_clear_port_change_bit(struct xhci_hcd
*xhci, u16 wValue,
port_change_bit = warm(BH) reset;
break;
case USB_PORT_FEAT_C_CONNECTION:
+ if ((xhci-quirks XHCI_DISCONNECT_QUIRK)
+ !(readl(addr) PORT_CONNECT))
+ return;
+
New port status event are prevented until CSC is cleared, not sure if there's
any harm in that?
hub thread would be aware of device detach before he try to clear PORTCSC, IIUC,
Despite I skip clearing PORTCSC here, whole device detach procedure
still behave normally.
status = PORT_CSC;
port_change_bit = connect;
break;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index c50d8d2..aa8e02a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3584,6 +3584,33 @@ command_cleanup:
return ret;
}
+static void xhci_try_to_clear_csc(struct usb_hcd *hcd, int dev_port_num)
+{
+ int max_ports;
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ __le32 __iomem **port_array;
+ u32 status;
+
+ /* print debug info */
+ if (hcd-speed == HCD_USB3) {
+ max_ports = xhci-num_usb3_ports;
+ port_array = xhci-usb3_ports;
+ } else {
+ max_ports = xhci-num_usb2_ports;
+ port_array = xhci-usb2_ports;
+ }
+
+ if (dev_port_num max_ports) {
+ xhci_err(xhci, %s() port number invalid, __func__);
+ return;
+ }
+ status = readl(port_array[dev_port_num - 1]);
+
+ /* write 1 to clear */
+ if (!(status PORT_CONNECT)
Re: n900 audio: any ideas how to get headset speaker to work?
On Sun 2015-02-15 12:08:02, Pali Rohár wrote: On Sunday 15 February 2015 11:21:52 Pavel Machek wrote: Hi! By default, output goes to loudspeaker (top right relative to keyboard). Any ideas how to switch it to the speaker on the left or wired headset? Because I suspect that echo cancelation is not going to be simple... Pavel I do not know but maybe this file could help: https://gitorious.org/community-ssu/policy-settings-rx51/source/dcb6429c12006dc9850cc942b7143358fe3fd330:rx51/etc/alsaped.conf There are definitions of alsa channels and settings for different profiles. Thanks... it seems to be what I needed. More code to write... 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
Re: n900 audio: any ideas how to get headset speaker to work?
On Sunday 15 February 2015 17:20:29 Pavel Machek wrote: On Sun 2015-02-15 12:08:02, Pali Rohár wrote: On Sunday 15 February 2015 11:21:52 Pavel Machek wrote: Hi! By default, output goes to loudspeaker (top right relative to keyboard). Any ideas how to switch it to the speaker on the left or wired headset? Because I suspect that echo cancelation is not going to be simple... Pavel I do not know but maybe this file could help: https://gitorious.org/community-ssu/policy-settings-rx51/sou rce/dcb6429c12006dc9850cc942b7143358fe3fd330:rx51/etc/alsape d.conf There are definitions of alsa channels and settings for different profiles. Thanks... it seems to be what I needed. More code to write... Pavel Will you create asoundrc file with both speakers for n900? I would like to see n900 sound setup without pulseaudio... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
[PATCH] serial: 8250: Revert tty: serial: 8250_core: read only RX if there is something in the FIFO
This reverts commit 0aa525d11859c1a4d5b78fdc704148e2ae03ae13. The conditional RX-FIFO read seems to cause spurious interrupts and we see just: |serial8250: too much work for irq29 The previous behaviour was default for decades and Marvell's 88f6282 SoC might not be the only that relies on it. Therefore the Omap fix is reverted for now. Fixes: 0aa525d11859 (tty: serial: 8250_core: read only RX if there is something in the FIFO) Reported-By: Nicolas Schichan nschic...@freebox.fr Debuged-By: Peter Hurley pe...@hurleysoftware.com Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- * Russell King - ARM Linux | 2015-02-13 23:15:19 [+]: On Fri, Feb 13, 2015 at 07:51:16PM +0100, Sebastian Andrzej Siewior wrote: Something like this maybe? My personal feeling is that as 0aa525d11859 was wrong, it should be reverted and this should be another attempt to fix the problem. In other words, there should be two patches, one a revert of the previously known bad commit and this one having another go at it. I feel that would be a better approach, since then we don't end up with this change building on a previously know buggy change. It would also make the changes to this solution from the previous, known-to-work-for-decades code more obvious. Okay. So here is the revert. drivers/tty/serial/8250/8250_core.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c index e3b9570a1eff..deae122c9c4b 100644 --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -2138,8 +2138,8 @@ int serial8250_do_startup(struct uart_port *port) /* * Clear the interrupt registers. */ - if (serial_port_in(port, UART_LSR) UART_LSR_DR) - serial_port_in(port, UART_RX); + serial_port_in(port, UART_LSR); + serial_port_in(port, UART_RX); serial_port_in(port, UART_IIR); serial_port_in(port, UART_MSR); @@ -2300,8 +2300,8 @@ int serial8250_do_startup(struct uart_port *port) * saved flags to avoid getting false values from polling * routines or the previous session. */ - if (serial_port_in(port, UART_LSR) UART_LSR_DR) - serial_port_in(port, UART_RX); + serial_port_in(port, UART_LSR); + serial_port_in(port, UART_RX); serial_port_in(port, UART_IIR); serial_port_in(port, UART_MSR); up-lsr_saved_flags = 0; @@ -2394,8 +2394,7 @@ void serial8250_do_shutdown(struct uart_port *port) * Read data port to reset things, and then unlink from * the IRQ chain. */ - if (serial_port_in(port, UART_LSR) UART_LSR_DR) - serial_port_in(port, UART_RX); + serial_port_in(port, UART_RX); serial8250_rpm_put(up); del_timer_sync(up-timer); -- 2.1.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
n900 audio: any ideas how to get headset speaker to work?
Hi! By default, output goes to loudspeaker (top right relative to keyboard). Any ideas how to switch it to the speaker on the left or wired headset? Because I suspect that echo cancelation is not going to be simple... 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
Re: n900 audio: any ideas how to get headset speaker to work?
On Sun 2015-02-15 17:27:03, Pali Rohár wrote: On Sunday 15 February 2015 17:20:29 Pavel Machek wrote: On Sun 2015-02-15 12:08:02, Pali Rohár wrote: On Sunday 15 February 2015 11:21:52 Pavel Machek wrote: Hi! By default, output goes to loudspeaker (top right relative to keyboard). Any ideas how to switch it to the speaker on the left or wired headset? Because I suspect that echo cancelation is not going to be simple... I do not know but maybe this file could help: https://gitorious.org/community-ssu/policy-settings-rx51/sou rce/dcb6429c12006dc9850cc942b7143358fe3fd330:rx51/etc/alsape d.conf There are definitions of alsa channels and settings for different profiles. Thanks... it seems to be what I needed. More code to write... Will you create asoundrc file with both speakers for n900? I would like to see n900 sound setup without pulseaudio... I actually have pulseaudio running (and plan to keep it since Debian has it by default). It seems mixer names changed a lot between Maemo kernel and 3.19. I have parser for alsaped.conf, but was not able to identify matching mixers. 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
Enabling DBGEN signal in GP OMAP3
Hi, Does anyone know if there is a way to make DBGEN signal high on OMAP3530 and/or DM3730 without using a hardware debugger? My goal is to make use of hardware watchpoints in Cortex-A8, but that requires DBGEN to be high. The TRM states: The DBGEM signal on the Cortex-A8 is driven by setting bit 13 at address 0x5401 D030 in the DAP-APB address space. However regardless of how hard I try the writes to that register seem to be ignored. I even tried to do it from IVA/C64x with no success. (I assume DBGEM is a typo since Cortex-A8 manuals have no mention of it, and they meant DBGEN there). It seems others had this problem too, and TI is as helpful as ever: http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/30011/104527 DBGEN is mentioned by Will Deacon's commit 8954bb0da99b76c7ce5edf2f314807cff68b6ea8 , but I guess he mixed NIDEN with DBGEN there (DBGAUTHSTATUS returns 0x00ae so NIDEN is indeed set here, and I have tried old kernel where OMAP3_EMU was still available). 0x5401D030 is referenced by some OpenOCD scripts, so I guess it's writeable over jtag, but not by the CPU(s). It's quite a mysterious otherwise undocumented register, I've noticed it's bit21 is some status bit related to Cortex-A8's low power states. Gražvydas -- 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
