Re: [PATCHv5 2/2] ASoC: TWL6040: Add twl6040 codec driver
On 16 Mar 2010, at 17:51, "Olaya, Margarita" wrote:
On Saturday, March 13, 2010 5:23 AM Felipe Balbi wrote:
Hi,
On Fri, 12 Mar 2010 19:52:20 -0600, "Olaya, Margarita"
wrote:
+/*
+ * twl6040 register cache & default register settings + */
+static const u8 twl6040_reg[TWL6040_CACHEREGNUM] = {
+ 0x00, /* not used 0x00*/
+ 0x4B, /* TWL6040_ASICID (ro)0x01*/
[snip]
a little comment about what the default values are would be nice.
Most of the codecs only have the register description, not sure if
this
is an standard in alsa. Some values are kind of hard to describe
briefly.
The standard is that these are the power on reset values, used to init
the register cache and reduce the amount of I/O done to restore on
resume.
#ifdef CONFIG_PM
+static int twl6040_suspend(struct platform_device *pdev,
[snip]
#else
#define twl6040_suspendNULL
#define twl6040_resume NULL
#endif
I'll add this.
Regards,
Margarita
--
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: [PATCHv5 2/2] ASoC: TWL6040: Add twl6040 codec driver
On Saturday, March 13, 2010 5:23 AM Felipe Balbi wrote:
> Hi,
>
> On Fri, 12 Mar 2010 19:52:20 -0600, "Olaya, Margarita"
> wrote:
>> +/*
>> + * twl6040 register cache & default register settings + */
>> +static const u8 twl6040_reg[TWL6040_CACHEREGNUM] = {
>> + 0x00, /* not used 0x00*/
>> + 0x4B, /* TWL6040_ASICID (ro)0x01*/
[snip]
>
> a little comment about what the default values are would be nice.
Most of the codecs only have the register description, not sure if this
is an standard in alsa. Some values are kind of hard to describe briefly.
>
> #ifdef CONFIG_PM
>
>> +static int twl6040_suspend(struct platform_device *pdev,
[snip]
>
> #else
> #define twl6040_suspendNULL
> #define twl6040_resume NULL
> #endif
I'll add this.
Regards,
Margarita
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
RE: [PATCH 1/2] OMAP4: PMIC: Rename twl6030_codec as twl6040_codec
On Saturday, March 13, 2010 5:18 AM Felipe Balbi wrote:
> Hi,
>
> On Fri, 12 Mar 2010 19:52:15 -0600, "Olaya, Margarita"
> wrote:
>
> please add a description here. Why do you need to rename it ?
Ok, I'll add a description. We were using twl6030 for Phoenix
Audio and Phoenix Power chips but Phoenix Audio is actually twl6040.
>
>> Signed-off-by: Margarita Olaya Cabrera
>
> [snip]
>
>> if (twl_has_codec() && pdata->codec && twl_class_is_6030()) {
>> sub_chip_id = twl_map[TWL_MODULE_AUDIO_VOICE].sid;
>> -child = add_child(sub_chip_id, "twl6030_codec",
>> +child = add_child(sub_chip_id, "twl6040_codec",
>
> you rename the platform_device but no the platform_driver ??
> how do you expect the driver to probe() ??
Platform_driver register is called in twl6040.c file, I haven't found an issue
at probe.
Re: [PATCH 2/2] USB: musb: omap2430: add mode change from A to B
Hi, On Tue, Mar 16, 2010 at 06:13:50PM +0800, wanghui wrote: > Thank you for your comments. > It is right that in this function, we should only change id pin rules > according to user's choice, and > leave mode transition to the ISR. > But things are different on omap platforms, because the id pin change > can't trigger ISR. > For example, when we configure the kernel, we choose musb working as OTG > mode. Then we plug a mini-A or a mini-B cable in the socket, after > that we execute insmod g_ether.ko, at this time, the musb will > initialize to A or B working mode. how to change > its working mode from A to B or B to A at this time? I think if the > platform can support id detection ISR, your method > is workable. But on omap platforms, we must change cable(id pin state) > manually first, then let the controller to re-initiate a session forcibly. > This action (clear/set session bit) don't 100% equal to send a SRP, and > i don't really want to send a SRP too. > > If without this function for omap platforms, we can change musb working > mode only through rebooting kernel or rmmod/insmod gadget driver module. it should be doable with the transceiver ISR. When you get id pin irq, you should put the transceiver into A_IDLE state and power up vbus. MUSB changes to host mode automatically. -- balbi -- 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 1/2] omap i2c: make errata 1.153 workaround a separate function
* Alexander Shishkin [100316 04:28]: > On Wed, Dec 16, 2009 at 04:02:23 +0200, Alexander Shishkin wrote: > > This is to avoid insanely long lines and levels of indentation. > > These seem to be forgotten. Is there any problem with these I should address? Can you please repost and I'll add those too into omap-testing first? Or maybe point to the right patchwork.kernel.org link. 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 1/2] omap i2c: make errata 1.153 workaround a separate function
On Wed, Dec 16, 2009 at 04:02:23 +0200, Alexander Shishkin wrote: > This is to avoid insanely long lines and levels of indentation. These seem to be forgotten. Is there any problem with these I should address? Regards, -- Alex -- 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 1/2] USB: musb: add two states to handle vbus error
On omap platforms, when configuring the kernel, if we choose the musb
work as host or OTG mode and we plug
a mini-A cable into the socket, after the kernel boot up in host mode or
insmod gadget driver in OTG mode,
the state of musb's xceiv is A_IDLE or B_IDLE correspondingly because id
change can't trigger ISR. Under this
condition, if we hotplug a usb device(without self-powered) at the other
side of the cable, the musb will suffer a vbus error,
This patch can handle this vbus error.
Wang Hui wrote:
When the MUSB is configured as host mode or OTG mode, the xceiv->state
will be set to OTG_STATE_A_IDLE or OTG_STATE_B_IDLE unconditionally
during init process. These init states can change to other
states When the MUSB module detects id pin change, devices connect or
disconnect.
But on some platforms(omap2, omap3), the id pin change
can't raise IRQ request to the MUSB module, so on these platforms,
the init xceiv->state will be A_IDLE or B_IDLE. Under this condition,
when we want the MUSB to act as a host and hotplug a usb device in
mini-B side of the cable, the MUSB will have a possibility to suffer
power underrun under A_IDLE or B_IDLE state, So here adding these
two states under which we can handle VBUSERROR IRQ.
Signed-off-by: Wang Hui
---
drivers/usb/musb/musb_core.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index b4bbf8f..655413c 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -516,6 +516,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
* another reset is due (at least for high speed,
* to redo the chirp etc), it might work OK...
*/
+ case OTG_STATE_A_IDLE:
+ case OTG_STATE_B_IDLE:
case OTG_STATE_A_WAIT_BCON:
case OTG_STATE_A_WAIT_VRISE:
if (musb->vbuserr_retry) {
--
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/2] USB: musb: omap2430: add mode change from A to B
Felipe Balbi wrote: On Mon, Mar 15, 2010 at 02:22:38PM +0300, Sergei Shtylyov wrote: The whole musb_platform_set_mode() seems to be implemented incorrectly on OMAPs -- it shouldn't touch the DevCtl.Session bit. This correct. It should be changing the id pin rules just like in tusb6010.c function should control the ID pin override instead -- if the controller supports it. SRP must be initiated thru other means, i.e. 'srp' file in sysfs. via musb_gadget_wakeup() Thank you for your comments. It is right that in this function, we should only change id pin rules according to user's choice, and leave mode transition to the ISR. But things are different on omap platforms, because the id pin change can't trigger ISR. For example, when we configure the kernel, we choose musb working as OTG mode. Then we plug a mini-A or a mini-B cable in the socket, after that we execute insmod g_ether.ko, at this time, the musb will initialize to A or B working mode. how to change its working mode from A to B or B to A at this time? I think if the platform can support id detection ISR, your method is workable. But on omap platforms, we must change cable(id pin state) manually first, then let the controller to re-initiate a session forcibly. This action (clear/set session bit) don't 100% equal to send a SRP, and i don't really want to send a SRP too. If without this function for omap platforms, we can change musb working mode only through rebooting kernel or rmmod/insmod gadget driver module. -- 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
