Re: [RFC][PATCH v2 00/13] USB: OTG/DRD Core functionality
On 23/04/15 04:52, Peter Chen wrote:
> On Wed, Apr 22, 2015 at 03:42:32PM +0300, Roger Quadros wrote:
>>> So we will have a separate drd fsm file, and the CONFIG_USB_OTG
>>> and CONFIG_USB_OTG_FSM are not needed to be defined, right?
>>>
>>
>> for drd case CONFIG_USB_OTG_FSM is definitely not needed.
>> I'm not sure if we can operate dual-role without CONFIG_USB_OTG.
>> I was thinking of combining the OTG core functionality
>> (drivers/usb/common/usb-otg.c)
>> with CONFIG_USB_OTG.
>>
>
> Ok, let's choose CONFIG_USB_OTG for both drd and usb fsm case.
> And we need to patch for hcd that only hnp supported hcd needs
> to request otg descriptor, etc.
Agreed. It makes things much simpler.
>
> For yesterday's back-compatible old otg device, we can add otg
> features to these drivers, the current behavior for these drivers
> is: if CONFIG_USB_OTG is defined, it is an otg device, we can just
> keep the behavior unchanging. If these drivers need to use OTG framework
> in future, it needs to update its platform data or dts.
Right.
>
> So, I prefer:
>
> - For switching the role through the ID pin devices, we doesn't need any otg
> features, so no otg dts properties are needed.(expect dr_mode = "otg")
> - For adp/srp/hnp supported devices, we need (partial) otg features, and
> the fsm (hardware or software) are needed, we need some otg dts
> properties we discussed before.
Agreed.
I will try to incorporate these points in v3 of this series.
cheers,
-roger
>
>
>>>
>>> static const struct usb_descriptor_header *otg_desc_20[] = {
>>> (struct usb_descriptor_header *) &(struct usb_otg_descriptor_20){
>>> .bLength = sizeof(struct usb_otg_descriptor_20),
>>> .bDescriptorType = USB_DT_OTG,
>>>
>>> /*
>>> * REVISIT SRP-only hardware is possible, although
>>> * it would not be called "OTG" ...
>>> */
>>> .bmAttributes = USB_OTG_SRP | USB_OTG_HNP,
>>> .bcdOTG = cpu_to_le16(0x0200),
>>> },
>>> NULL,
>>> };
>>
>> instead of hardcoding bmAttributes field, it must be obtained from the
>> appropriate data structure that was set by the controller driver
>> by reading DT and OTG hardware info.
>>
>>>
>>> During bind process:
>>>
>>> if (gadget_is_otg_13(c->cdev->gadget))
>>> c->descriptors = otg_desc_13;
>>> else if (gadget_is_otg_20(c->cdev->gadget))
>>> c->descriptors = otg_desc_20;
>>
>> Probably a helper utitily can do the necessary checks and build the
>> otg descriptor for us.
>> usb_otg_get_descriptor(c->descriptors);
>>
>> e.g. for OTG3.0 we have a new flag USB_OTG_RSP, and this helper
>> can be upgraded in the future.
>
> ok, it is the implementation detail.
>
--
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: [RFC][PATCH v2 00/13] USB: OTG/DRD Core functionality
On Wed, Apr 22, 2015 at 03:42:32PM +0300, Roger Quadros wrote:
> > So we will have a separate drd fsm file, and the CONFIG_USB_OTG
> > and CONFIG_USB_OTG_FSM are not needed to be defined, right?
> >
>
> for drd case CONFIG_USB_OTG_FSM is definitely not needed.
> I'm not sure if we can operate dual-role without CONFIG_USB_OTG.
> I was thinking of combining the OTG core functionality
> (drivers/usb/common/usb-otg.c)
> with CONFIG_USB_OTG.
>
Ok, let's choose CONFIG_USB_OTG for both drd and usb fsm case.
And we need to patch for hcd that only hnp supported hcd needs
to request otg descriptor, etc.
For yesterday's back-compatible old otg device, we can add otg
features to these drivers, the current behavior for these drivers
is: if CONFIG_USB_OTG is defined, it is an otg device, we can just
keep the behavior unchanging. If these drivers need to use OTG framework
in future, it needs to update its platform data or dts.
So, I prefer:
- For switching the role through the ID pin devices, we doesn't need any otg
features, so no otg dts properties are needed.(expect dr_mode = "otg")
- For adp/srp/hnp supported devices, we need (partial) otg features, and
the fsm (hardware or software) are needed, we need some otg dts
properties we discussed before.
> >
> > static const struct usb_descriptor_header *otg_desc_20[] = {
> > (struct usb_descriptor_header *) &(struct usb_otg_descriptor_20){
> > .bLength = sizeof(struct usb_otg_descriptor_20),
> > .bDescriptorType = USB_DT_OTG,
> >
> > /*
> > * REVISIT SRP-only hardware is possible, although
> > * it would not be called "OTG" ...
> > */
> > .bmAttributes = USB_OTG_SRP | USB_OTG_HNP,
> > .bcdOTG = cpu_to_le16(0x0200),
> > },
> > NULL,
> > };
>
> instead of hardcoding bmAttributes field, it must be obtained from the
> appropriate data structure that was set by the controller driver
> by reading DT and OTG hardware info.
>
> >
> > During bind process:
> >
> > if (gadget_is_otg_13(c->cdev->gadget))
> > c->descriptors = otg_desc_13;
> > else if (gadget_is_otg_20(c->cdev->gadget))
> > c->descriptors = otg_desc_20;
>
> Probably a helper utitily can do the necessary checks and build the
> otg descriptor for us.
> usb_otg_get_descriptor(c->descriptors);
>
> e.g. for OTG3.0 we have a new flag USB_OTG_RSP, and this helper
> can be upgraded in the future.
ok, it is the implementation detail.
--
Best Regards,
Peter Chen
--
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] omap: i2c: Add calls for pinctrl state select
few nitpicks: i2c: omap: in $subject instead of omap: i2c: I usually would do: git log --no-merges --oneline drivers/i2c/busses/i2c-omap.c and look for common usage. On 04/22/2015 04:07 AM, pascal.hue...@gmail.com wrote: > From: Pascal Huerst > > This adds calls to pinctrl subsystem in order to switch pin states > on suspend/resume if you provide a "sleep" state in DT. > > Signed-off-by: Pascal Huerst > --- > drivers/i2c/busses/i2c-omap.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index 0e89419..8261941 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -38,6 +38,7 @@ > #include > #include > #include > +#include > > /* I2C controller revisions */ > #define OMAP_I2C_OMAP1_REV_2 0x20 > @@ -1423,6 +1424,8 @@ static int omap_i2c_runtime_suspend(struct device *dev) > omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); > } > > + pinctrl_pm_select_sleep_state(dev); > + > return 0; > } > > @@ -1431,6 +1434,8 @@ static int omap_i2c_runtime_resume(struct device *dev) > struct platform_device *pdev = to_platform_device(dev); > struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); > > + pinctrl_pm_select_default_state(dev); > + > if (!_dev->regs) > return 0; > > -- > 2.1.0 > Build tested with omap2plus_defconfig on linus master (27cf3a16b253) and next-20150422 While I do understand that the sleep state and default states are optional - might be nice to state it in commit message (as a result of which we dont do error checks). Would you think adding relevant documentation in Documentation/devicetree/bindings/i2c/i2c-omap.txt might be good as well? I mean, folks should know looking at dt documentation that this bus driver does indeed support this option.. -- Regards, Nishanth Menon -- 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] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 04/22/2015 06:30 AM, Alexandre Belloni wrote: Apologies on a tardy response, got dragged into another issue and got cooped up in lab whole day. > On 21/04/2015 at 20:59:15 -0500, Nishanth Menon wrote : Why is that so? when set alarm is requested for time X, you want interrupt at time X, not an interrupt for previous configured RTC alarm time! >>> >>> You expect at least an interrupt. >> >> And you will get an interrupt if the event occurs before the i2c burst >> starts. Once the i2cburst does start, you are committing to the new time. >> > > You mean that even if ALM0EN is set after ALM0IF was set to 1, it will > trigger the interrupt? I had a look at the MFP output block diagram > would let me think that this is the case. I was thinking otherwise > before. If that is so, then indeed, your patch is OK. At least based on my testing it seems to be the case, and as you can see in the block diagram, the ALM0EN mux comes after ALM0IF.. agreed that I am not sure the mux to have some internal buffers/latches etc.. dont have access to rtl to make more comments. > > My concern was about the time between ds1307->write_block_data() and > i2c_smbus_write_byte_data() which actually calls cond_sched(). > > I fully agree that your patch doesn't change the behaviour for the other > cases you presented and further clean up is to be done in a separate set > of patches. > Can I take this as an Acked-by? -- Regards, Nishanth Menon -- 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] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 04/22/2015 08:26 AM, grygorii.stras...@linaro.org wrote: > Hi, > > On 04/21/2015 03:51 AM, Nishanth Menon wrote: >> Alarm interrupt enable register is at offset 0x7, while the time >> registers for the alarm follow that. When we program Alarm interrupt >> enable prior to programming the time, it is possible that previous >> time value could be close or match at the time of alarm enable >> resulting in interrupt trigger which is unexpected (and does not match >> the time we expect it to trigger). >> >> To prevent this scenario from occuring, program the ALM0_EN bit only >> after the alarm time is appropriately programmed. >> >> Ofcourse, I2C programming is non-atomic, so there are loopholes where >> the interrupt wont trigger if the time requested is in the past at >> the time of programming the ALM0_EN bit. However, we will not have >> unexpected interrupts while the time is programmed after the interrupt >> are enabled. > > I think it will be nice if you will mention that you going to follow > vendor recommendations - AN1491 Configuring the MCP794XX RTCC Family > http://ww1.microchip.com/downloads/en/AppNotes/01491A.pdf > ;) > "Also, it is recommended that the alarm registers be loaded > before the alarm is enabled." > Hmm... i did not know that existed, thanks for digging it up.. that teaches me to look for docs before putting a scope/LA on the board (not that I regret doing that)... That said, reading the app note, I kind of realized: a) that playing with ST bit for programming time is not done, but then, that implies that oscillator will have to be restarted (upto a few seconds for certain crystals).. but that said, it does not seem mandatory or seem to (yet seen) functional issues... b) We dont have flexibility yet to describe if we do indeed have a backup battery or not - VBATEN should be set only if we have a backup battery on the platform :( - on some it might even be optional thanks to certain compliance requirements of shipping boards internationally and general "unlike" of lithium ion in cargo hold.. c) we dont have capability to control the alarm polarity in the driver which, by the way, we probably should also control OUT polarity (when ALARM is not asserted).. d) we dont have support for external 32k oscillator(X1 only) instead of assuming we always have a 32k crystal(X1 and X2)... Ugghhh... more cleaning up to do for the future.. that said, the sequence it does recommend (in page 4): The following steps show how the Alarm 0 is config- ured. Alarm 1 can be configured in the same manner. 1.Write 0x23 to the Alarm0 Seconds register [0x0A]. 2.Write 0x47 to the Alarm0 Minutes register [0x0B]. 3.Write 0x71 to the Alarm0 Hours register [0x0C] – 11 hours in 12-hour format. 4.Write 0x72 to the Alarm0 Day register [0x0D] – Tuesday + Alarm Polarity Low + Match on all. The Alarm0 Interrupt Flag is also cleared. 5.Write 0x14 to the Alarm0 Date register [0x0E]. 6.Write 0x08 to the Alarm0 Month register [0x0F]. With all the Alarm0 registers set we can now activate the Alarm0 on the Control register. 7.Write 0x10 to the Control register [0x07] – Alarm0 enabled no CLKOUT, Alarm1 disabled before this patch we do ( http://pastebin.ubuntu.com/10863880/) CONTROL r[7] = 0x90 (OUT=1, ALM0EN=1) OSCTRIM r[8] = 0x00 EEUNLOCK r[9] = 0x00 ALM0SEC r[A] = 0x01 ALM0MIN r[B] = 0x45 ALM0HOUR r[C] = 0x23 ALM0WKDAY r[D] = 0x75 <-ALMOIF is cleared ALM0DATE r[E] = 0x09 ALM0MTH r[F] = 0x04 RSRVED r[10] = 0x01 with this patch, we do: burst( CONTROL r[7] = 0x80 (OUT=1) OSCTRIM r[8] = 0x00 EEUNLOCK r[9] = 0x00 ALM0SEC r[A] = 0x01 ALM0MIN r[B] = 0x45 ALM0HOUR r[C] = 0x23 ALM0WKDAY r[D] = 0x75 <-ALMOIF is cleared ALM0DATE r[E] = 0x09 ALM0MTH r[F] = 0x04 RSRVED r[10] = 0x01 ) CONTROL r[7] = 0x90 (OUT=1, ALM0EN=1) Which is slightly unoptimal way of what the app note recommends. - as I mentioned earlier in this thread, I will try and do optimizations in a later patch. Given that Andrew had picked up this patch, I dont see a reason to respin this yet.. but will include the app note for future patches - thanks for pointing it out to me. >> >> Signed-off-by: Nishanth Menon >> --- >> Changes in v2: >> - minor typo fix in comments >> - merged up code that I missed committing in >> >> V1: https://patchwork.kernel.org/patch/6245041/ >> >> drivers/rtc/rtc-ds1307.c | 12 ++-- >> 1 file changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c >> index 4ffabb322a9a..3cd4783375a5 100644 >> --- a/drivers/rtc/rtc-ds1307.c >> +++ b/drivers/rtc/rtc-ds1307.c >> @@ -742,17 +742,17 @@ static int mcp794xx_set_alarm(struct device *dev, >> struct rtc_wkalrm *t) >> regs[6] &= ~MCP794XX_BIT_ALMX_IF; >> /* Set alarm match: second, minute, hour, day, date, month. */ >>
[BUG?] drivers: net:ethernet: cpsw: add support for VLAN
Hi,
has commit 3b72c2fe0c6bbec42e ("drivers: net:ethernet: cpsw: add
support for VLAN") introduced a bug by defining CPSW_VLAN_AWARE as
BIT(1) instead of BIT(2)?
+#define CPSW_VLAN_AWAREBIT(1)
/* switch to vlan unaware mode */
- cpsw_ale_control_set(priv->ale, 0, ALE_VLAN_AWARE, 0);
+ cpsw_ale_control_set(priv->ale, priv->host_port, ALE_VLAN_AWARE,
+CPSW_ALE_VLAN_AWARE);
+ control_reg = readl(&priv->regs->control);
+ control_reg |= CPSW_VLAN_AWARE;
+ writel(control_reg, &priv->regs->control);
See TRM [1] page 1980 (14.5.1.2 CONTROL Register), there bit
CPSW_VLAN_AWARE is number 2.
I didn't do any tests, just stumbled upon.
[1]: http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf
Thanks
-- Christoph
--
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/5] ASoC: omap-hdmi-audio: Force channel allocation only for OMAP4
On Wed, Apr 22, 2015 at 04:23:00PM +0300, Jyri Sarha wrote: > From: Misael Lopez Cruz > > There is a constraint in the OMAP4 HDMI IP that requires to use > the 8-channel code when transmitting more than two channels. Acked-by: Mark Brown signature.asc Description: Digital signature
Re: [PATCH 5/5] ASoC: omap-hdmi-audio: Fix invalid combination of DM_INH and CA
On Wed, Apr 22, 2015 at 04:23:01PM +0300, Jyri Sarha wrote: > From: Misael Lopez Cruz > > DM_INH = 1 (stereo downmix prohibited) and CA = 0x00 (Channel > Allocation: FR, FL) is an invalid combination according to the > HDMI Compliance Test 7.31 "Audio InfoFrame". Acked-by: Mark Brown signature.asc Description: Digital signature
Re: [PATCH 1/1] ARM: OMAP2+: Fix omap3 off idle power consumption creeping up
* Nishanth Menon [150421 19:10]:
> On 04/21/2015 08:00 PM, Tony Lindgren wrote:
> > + /*
> > +* Note that for omap3 OMAP3430_SREN_MASK clears SREN to work around
> > +* erratum i531 "Extra Power Consumed When Repeated Start Operation
> > +* Mode Is Enabled on I2C Interface Dedicated for Smart Reflex (I2C4)".
> > +* Otherwise I2C4 eventually leads into about 23mW extran power being
>
> nitpick: extran ;)
Thanks fixed.
> > @@ -40,6 +40,7 @@ static struct omap_vc_common omap3_vc_common = {
> > .cmd_onlp_shift = OMAP3430_VC_CMD_ONLP_SHIFT,
> > .cmd_ret_shift = OMAP3430_VC_CMD_RET_SHIFT,
> > .cmd_off_shift = OMAP3430_VC_CMD_OFF_SHIFT,
> > + .i2c_cfg_clear_mask = OMAP3430_SREN_MASK,
>
> I know that the prminst rmw current code does:
> v &= ~mask;
> v |= bits;
> and not
> v &= ~mask;
> v |= (bits & mask);
> but to maintain legacy behavior in case the PRCM cleanup sequences
> change anything..
>
> .i2c_cfg_clear_mask = OMAP3430_SREN_MASK | OMAP3430_HSEN_MASK,
> ?
> or
> voltdm->rmw(vc->common->i2c_cfg_clear_mask |
> vc->common->i2c_cfg_hsen_mask,
> vc->common->i2c_cfg_hsen_mask,
> vc->common->i2c_cfg_reg);
>
> no strong feelings though...
OK updated to use OMAP3430_SREN_MASK | OMAP3430_HSEN_MASK.
> otherwise, please feel to add:
> Reviewed-by: Nishanth Menon
Thanks added updated patch below.
Regards,
Tony
8< --
From: Tony Lindgren
Date: Tue, 21 Apr 2015 14:31:23 -0700
Subject: [PATCH] ARM: OMAP2+: Fix omap off idle power consumption creeping up
If we use a combination of VMODE and I2C4 for retention modes,
eventually the off idle power consumption will creep up by about
23mW, even during off mode with I2C4 always staying enabled.
Turns out this is because of erratum i531 "Extra Power Consumed
When Repeated Start Operation Mode Is Enabled on I2C Interface
Dedicated for Smart Reflex (I2C4)" as pointed out by Nishanth
Menon .
Let's fix the issue by adding i2c_cfg_clear_mask for the bits
to clear when initializing the I2C4 adapter so we can clear
SREN bit that drives the I2C4 lines low otherwise when there
is no traffic.
Fixes: 3b8c4ebb7630 ("ARM: OMAP3: Fix idle mode signaling for
sys_clkreq and sys_off_mode")
Cc: Kevin Hilman
Cc: Tero Kristo
Reviewed-by: Nishanth Menon
Signed-off-by: Tony Lindgren
--- a/arch/arm/mach-omap2/prm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-34xx.h
@@ -112,6 +112,7 @@
#define OMAP3430_VC_CMD_ONLP_SHIFT 16
#define OMAP3430_VC_CMD_RET_SHIFT 8
#define OMAP3430_VC_CMD_OFF_SHIFT 0
+#define OMAP3430_SREN_MASK (1 << 4)
#define OMAP3430_HSEN_MASK (1 << 3)
#define OMAP3430_MCODE_MASK(0x7 << 0)
#define OMAP3430_VALID_MASK(1 << 24)
--- a/arch/arm/mach-omap2/prm-regbits-44xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-44xx.h
@@ -35,6 +35,7 @@
#define OMAP4430_GLOBAL_WARM_SW_RST_SHIFT 1
#define OMAP4430_GLOBAL_WUEN_MASK (1 <<
16)
#define OMAP4430_HSMCODE_MASK (0x7 <<
0)
+#define OMAP4430_SRMODEEN_MASK (1 << 4)
#define OMAP4430_HSMODEEN_MASK (1 << 3)
#define OMAP4430_HSSCLL_SHIFT 24
#define OMAP4430_ICEPICK_RST_SHIFT 9
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -316,7 +316,8 @@ static void __init omap3_vc_init_pmic_signaling(struct
voltagedomain *voltdm)
* idle. And we can also scale voltages to zero for off-idle.
* Note that no actual voltage scaling during off-idle will
* happen unless the board specific twl4030 PMIC scripts are
-* loaded.
+* loaded. See also omap_vc_i2c_init for comments regarding
+* erratum i531.
*/
val = voltdm->read(OMAP3_PRM_VOLTCTRL_OFFSET);
if (!(val & OMAP3430_PRM_VOLTCTRL_SEL_OFF)) {
@@ -704,9 +705,16 @@ static void __init omap_vc_i2c_init(struct voltagedomain
*voltdm)
return;
}
+ /*
+* Note that for omap3 OMAP3430_SREN_MASK clears SREN to work around
+* erratum i531 "Extra Power Consumed When Repeated Start Operation
+* Mode Is Enabled on I2C Interface Dedicated for Smart Reflex (I2C4)".
+* Otherwise I2C4 eventually leads into about 23mW extra power being
+* consumed even during off idle using VMODE.
+*/
i2c_high_speed = voltdm->pmic->i2c_high_speed;
if (i2c_high_speed)
- voltdm->rmw(vc->common->i2c_cfg_hsen_mask,
+ voltdm->rmw(vc->common->i2c_cfg_clear_mask,
vc->common->i2c_cfg_hsen_mask,
Re: [PATCH 1/1] gpio: omap: Fix PM runtime issue and remove most BANK_USED macros
On Tue, Apr 21, 2015 at 09:08:53AM -0700, Tony Lindgren wrote: > Looks like omap_gpio_irq_type can return early at several places > leaving a GPIO bank enabled without doing pm_runtime_put if wrong > GPIO arguments are passed. > > Instead of adding more complicated BANK_USED macros, let's fix the > issue properly. We can pass is_irq flag to omap_enable_gpio_module > and omap_disble_gpio_module. And with that we can remove all the > similar code elsewhere to get rid of most BANK_USED macros. > > Note that the reason for the BANK_USED macro is that we need to manage > PM runtime on per GPIO bank basis. In the long run we want to move to > using PM runtime counts for each GPIO line to determine if a GPIO > bank is used. Once we have a solution for omap_enable_gpio_module > and omap_disable_gpio_module, we can remove the remaining BANK_USED > macros. > > Cc: Felipe Balbi > Cc: Grygorii Strashko > Cc: Javier Martinez Canillas > Cc: Nishanth Menon > Signed-off-by: Tony Lindgren looks ok to my eyes. Reviewed-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH V2] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
Hi, On 04/21/2015 03:51 AM, Nishanth Menon wrote: > Alarm interrupt enable register is at offset 0x7, while the time > registers for the alarm follow that. When we program Alarm interrupt > enable prior to programming the time, it is possible that previous > time value could be close or match at the time of alarm enable > resulting in interrupt trigger which is unexpected (and does not match > the time we expect it to trigger). > > To prevent this scenario from occuring, program the ALM0_EN bit only > after the alarm time is appropriately programmed. > > Ofcourse, I2C programming is non-atomic, so there are loopholes where > the interrupt wont trigger if the time requested is in the past at > the time of programming the ALM0_EN bit. However, we will not have > unexpected interrupts while the time is programmed after the interrupt > are enabled. I think it will be nice if you will mention that you going to follow vendor recommendations - AN1491 Configuring the MCP794XX RTCC Family http://ww1.microchip.com/downloads/en/AppNotes/01491A.pdf ;) "Also, it is recommended that the alarm registers be loaded before the alarm is enabled." > > Signed-off-by: Nishanth Menon > --- > Changes in v2: > - minor typo fix in comments > - merged up code that I missed committing in > > V1: https://patchwork.kernel.org/patch/6245041/ > > drivers/rtc/rtc-ds1307.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c > index 4ffabb322a9a..3cd4783375a5 100644 > --- a/drivers/rtc/rtc-ds1307.c > +++ b/drivers/rtc/rtc-ds1307.c > @@ -742,17 +742,17 @@ static int mcp794xx_set_alarm(struct device *dev, > struct rtc_wkalrm *t) > regs[6] &= ~MCP794XX_BIT_ALMX_IF; > /* Set alarm match: second, minute, hour, day, date, month. */ > regs[6] |= MCP794XX_MSK_ALMX_MATCH; > - > - if (t->enabled) > - regs[0] |= MCP794XX_BIT_ALM0_EN; > - else > - regs[0] &= ~MCP794XX_BIT_ALM0_EN; > + /* Disable interrupt. We will not enable until completely programmed */ > + regs[0] &= ~MCP794XX_BIT_ALM0_EN; > > ret = ds1307->write_block_data(client, MCP794XX_REG_CONTROL, 10, regs); > if (ret < 0) > return ret; > > - return 0; > + if (!t->enabled) > + return 0; > + regs[0] |= MCP794XX_BIT_ALM0_EN; > + return i2c_smbus_write_byte_data(client, MCP794XX_REG_CONTROL, regs[0]); So, It seems, that right sequence should be: - disable alarmX - read alarmX regs - configure alarmX regs - load alarmX regs - enable alarmX More over, looks like, alarm/alarm IRQ should be enabled/disabled separately from set_alarm/RTC_ALM_SET by RTC_AIE_ON, RTC_AIE_OFF. Should it? > } > > static int mcp794xx_alarm_irq_enable(struct device *dev, unsigned int > enabled) > -- regards, -grygorii -- 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/5] ASoC: omap-hdmi-audio: Force channel allocation only for OMAP4
From: Misael Lopez Cruz There is a constraint in the OMAP4 HDMI IP that requires to use the 8-channel code when transmitting more than two channels. The constraint doesn't apply for OMAP5 so don't force the channel allocation in the sound driver as it can be done specifically for OMAP4 later in the hdmi4 core. Signed-off-by: Misael Lopez Cruz Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/hdmi4_core.c | 7 +++ sound/soc/omap/omap-hdmi-audio.c | 6 ++ 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/video/fbdev/omap2/dss/hdmi4_core.c b/drivers/video/fbdev/omap2/dss/hdmi4_core.c index 2b8bd22..fa72e73 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi4_core.c +++ b/drivers/video/fbdev/omap2/dss/hdmi4_core.c @@ -654,6 +654,13 @@ static void hdmi_core_audio_infoframe_cfg(struct hdmi_core_data *core, hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(2), info_aud->db3); sum += info_aud->db3; + /* +* The OMAP HDMI IP requires to use the 8-channel channel code when +* transmitting more than two channels. +*/ + if (info_aud->db4_ca != 0x00) + info_aud->db4_ca = 0x13; + hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(3), info_aud->db4_ca); sum += info_aud->db4_ca; diff --git a/sound/soc/omap/omap-hdmi-audio.c b/sound/soc/omap/omap-hdmi-audio.c index 4775da4..8df303f 100644 --- a/sound/soc/omap/omap-hdmi-audio.c +++ b/sound/soc/omap/omap-hdmi-audio.c @@ -210,12 +210,10 @@ static int hdmi_dai_hw_params(struct snd_pcm_substream *substream, cea->db3 = 0; /* not used, all zeros */ - /* -* The OMAP HDMI IP requires to use the 8-channel channel code when -* transmitting more than two channels. -*/ if (params_channels(params) == 2) cea->db4_ca = 0x0; + else if (params_channels(params) == 6) + cea->db4_ca = 0xb; else cea->db4_ca = 0x13; -- 1.9.1 -- 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 0/5] OMAPDSS: HDMI audio compliance fixes
I have rebased these patches from ti-linux-3.14.y on top of Linux 4.0.0. I tested them briefly on OMAP4 and OMAP5 in my environment, but I could not test any channel count beyond stereo. However, there were no conflicts in the rebase and each fix makes sense when looking at the chip TRM and the relevant HDMI specs. All the changes are really minor, but most of them apply to OMAPDSS side, so it is probably best to merge them trough there. Best regards, Jyri Misael Lopez Cruz (5): OMAPDSS: HDMI4: Set correct CC for 8-channels layout OMAPDSS: HDMI5: Set valid sample order OMAPDSS: HDMI5: Fix AUDICONF3 bitfield offsets ASoC: omap-hdmi-audio: Force channel allocation only for OMAP4 ASoC: omap-hdmi-audio: Fix invalid combination of DM_INH and CA drivers/video/fbdev/omap2/dss/hdmi4_core.c | 12 +++- drivers/video/fbdev/omap2/dss/hdmi5_core.c | 5 - sound/soc/omap/omap-hdmi-audio.c | 12 +++- 3 files changed, 22 insertions(+), 7 deletions(-) -- 1.9.1 -- 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 3/5] OMAPDSS: HDMI5: Fix AUDICONF3 bitfield offsets
From: Misael Lopez Cruz Downmix inhibit in HDMI_CORE_FC_AUDICONF3 register is in bit 4 while CEA861_AUDIO_INFOFRAME_DB5_DM_INH sets bit 7. Signed-off-by: Misael Lopez Cruz Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/hdmi5_core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/hdmi5_core.c b/drivers/video/fbdev/omap2/dss/hdmi5_core.c index 7a80beb..c3286bd 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5_core.c +++ b/drivers/video/fbdev/omap2/dss/hdmi5_core.c @@ -790,7 +790,9 @@ static void hdmi5_core_audio_infoframe_cfg(struct hdmi_core_data *core, hdmi_write_reg(base, HDMI_CORE_FC_AUDICONF1, info_aud->db2_sf_ss); hdmi_write_reg(base, HDMI_CORE_FC_AUDICONF2, info_aud->db4_ca); - hdmi_write_reg(base, HDMI_CORE_FC_AUDICONF3, info_aud->db5_dminh_lsv); + hdmi_write_reg(base, HDMI_CORE_FC_AUDICONF3, + (info_aud->db5_dminh_lsv & CEA861_AUDIO_INFOFRAME_DB5_DM_INH) >> 3 | + (info_aud->db5_dminh_lsv & CEA861_AUDIO_INFOFRAME_DB5_LSV)); } int hdmi5_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, -- 1.9.1 -- 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/5] ASoC: omap-hdmi-audio: Fix invalid combination of DM_INH and CA
From: Misael Lopez Cruz DM_INH = 1 (stereo downmix prohibited) and CA = 0x00 (Channel Allocation: FR, FL) is an invalid combination according to the HDMI Compliance Test 7.31 "Audio InfoFrame". Signed-off-by: Misael Lopez Cruz Signed-off-by: Jyri Sarha --- sound/soc/omap/omap-hdmi-audio.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sound/soc/omap/omap-hdmi-audio.c b/sound/soc/omap/omap-hdmi-audio.c index 8df303f..aeef25c 100644 --- a/sound/soc/omap/omap-hdmi-audio.c +++ b/sound/soc/omap/omap-hdmi-audio.c @@ -217,7 +217,11 @@ static int hdmi_dai_hw_params(struct snd_pcm_substream *substream, else cea->db4_ca = 0x13; - cea->db5_dminh_lsv = CEA861_AUDIO_INFOFRAME_DB5_DM_INH_PROHIBITED; + if (cea->db4_ca == 0x00) + cea->db5_dminh_lsv = CEA861_AUDIO_INFOFRAME_DB5_DM_INH_PERMITTED; + else + cea->db5_dminh_lsv = CEA861_AUDIO_INFOFRAME_DB5_DM_INH_PROHIBITED; + /* the expression is trivial but makes clear what we are doing */ cea->db5_dminh_lsv |= (0 & CEA861_AUDIO_INFOFRAME_DB5_LSV); -- 1.9.1 -- 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/5] OMAPDSS: HDMI5: Set valid sample order
From: Misael Lopez Cruz As per TRM, HDMI_WP_AUDIO_CFG[2] LEFT_BEFORE = 0 is reserved, so it must always be set to 1 (the first sample is the left). Signed-off-by: Misael Lopez Cruz Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/hdmi5_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/omap2/dss/hdmi5_core.c b/drivers/video/fbdev/omap2/dss/hdmi5_core.c index a3cfe3d..7a80beb 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5_core.c +++ b/drivers/video/fbdev/omap2/dss/hdmi5_core.c @@ -870,6 +870,7 @@ int hdmi5_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, audio_format.samples_per_word = HDMI_AUDIO_ONEWORD_TWOSAMPLES; audio_format.sample_size = HDMI_AUDIO_SAMPLE_16BITS; audio_format.justification = HDMI_AUDIO_JUSTIFY_LEFT; + audio_format.sample_order = HDMI_AUDIO_SAMPLE_LEFT_FIRST; /* only LPCM atm */ audio_format.type = HDMI_AUDIO_TYPE_LPCM; -- 1.9.1 -- 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/5] OMAPDSS: HDMI4: Set correct CC for 8-channels layout
From: Misael Lopez Cruz
OMAP4 HDMI IP uses the 8-channel layout with 8-channel speaker
allocation mask when transmitting more than two channels. But
the channel count field (CC) of the Audio InfoFrame's DB1 is
not updated for 8-channels.
As per HDMI Compliance Test 7.31 "Audio InfoFrame", CC = 7 is
required for 8-channels CA masks (0x13 and 0x1F).
Signed-off-by: Misael Lopez Cruz
Signed-off-by: Jyri Sarha
---
drivers/video/fbdev/omap2/dss/hdmi4_core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4_core.c
b/drivers/video/fbdev/omap2/dss/hdmi4_core.c
index 7eafea5..2b8bd22 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4_core.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4_core.c
@@ -795,7 +795,9 @@ int hdmi4_audio_config(struct hdmi_core_data *core, struct
hdmi_wp_data *wp,
/*
* the HDMI IP needs to enable four stereo channels when transmitting
-* more than 2 audio channels
+* more than 2 audio channels. Similarly, the channel count in the
+* Audio InfoFrame has to match the sample_present bits (some channels
+* are padded with zeroes)
*/
if (channel_count == 2) {
audio_format.stereo_channels = HDMI_AUDIO_STEREO_ONECHANNEL;
@@ -807,6 +809,7 @@ int hdmi4_audio_config(struct hdmi_core_data *core, struct
hdmi_wp_data *wp,
HDMI_AUDIO_I2S_SD1_EN | HDMI_AUDIO_I2S_SD2_EN |
HDMI_AUDIO_I2S_SD3_EN;
acore.layout = HDMI_AUDIO_LAYOUT_8CH;
+ audio->cea->db1_ct_cc = 7;
}
acore.en_spdif = false;
--
1.9.1
--
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] thermal: ti-soc-thermal: dra7: Implement Workaround for Errata i813
On Thursday 16 April 2015 03:48 PM, Keerthy wrote:
DESCRIPTION
Spurious Thermal Alert: Talert can happen randomly while the device remains
under the temperature limit
defined for this event to trig. This spurious event is caused by a incorrect
re-synchronization between
clock domains. The comparison between configured threshold and current
temperature value can happen
while the value is transitioning (metastable), thus causing inappropriate event
generation.
No spurious event occurs as long as the threshold value stays unchanged.
Spurious event can be
generated while a thermal alert threshold is modified in
CONTROL_BANDGAP_THRESHOLD_MPU/GPU/CORE/DSPEVE/IVA_n.
WORKAROUND
Spurious event generation can be avoided by performing following sequence when
the threshold is
modified:
1. Mask the hot/cold events at the thermal IP level.
2. Modify Threshold.
3. Unmask the hot/cold events at the thermal IP level.
Hi Eduardo,
I got a confirmation that the errata is applicable only to OMPA5 and not
DRA7. I have posted a fresh series with that taken care.
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg116354.html
Thanks,
Keerthy
Signed-off-by: Keerthy
---
.../thermal/ti-soc-thermal/dra752-thermal-data.c | 3 +-
drivers/thermal/ti-soc-thermal/ti-bandgap.c| 41 +-
drivers/thermal/ti-soc-thermal/ti-bandgap.h| 4 ++-
3 files changed, 45 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
b/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
index 58b5c66..4cd051d 100644
--- a/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
+++ b/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
@@ -421,7 +421,8 @@ const struct ti_bandgap_data dra752_data = {
TI_BANDGAP_FEATURE_TALERT |
TI_BANDGAP_FEATURE_COUNTER_DELAY |
TI_BANDGAP_FEATURE_HISTORY_BUFFER |
- TI_BANDGAP_FEATURE_ERRATA_814,
+ TI_BANDGAP_FEATURE_ERRATA_814 |
+ TI_BANDGAP_FEATURE_ERRATA_813,
.fclock_name = "l3instr_ts_gclk_div",
.div_ck_name = "l3instr_ts_gclk_div",
.conv_table = dra752_adc_to_temp,
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 94acd80..c2c585a 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -445,7 +445,7 @@ static int ti_bandgap_update_alert_threshold(struct
ti_bandgap *bgp, int id,
{
struct temp_sensor_data *ts_data = bgp->conf->sensors[id].ts_data;
struct temp_sensor_registers *tsr;
- u32 thresh_val, reg_val, t_hot, t_cold;
+ u32 thresh_val, reg_val, t_hot, t_cold, ctrl;
int err = 0;
tsr = bgp->conf->sensors[id].registers;
@@ -477,8 +477,47 @@ static int ti_bandgap_update_alert_threshold(struct
ti_bandgap *bgp, int id,
~(tsr->threshold_thot_mask | tsr->threshold_tcold_mask);
reg_val |= (t_hot << __ffs(tsr->threshold_thot_mask)) |
(t_cold << __ffs(tsr->threshold_tcold_mask));
+
+ /**
+* Errata i813:
+* Spurious Thermal Alert: Talert can happen randomly while the device
+* remains under the temperature limit defined for this event to trig.
+* This spurious event is caused by a incorrect re-synchronization
+* between clock domains. The comparison between configured threshold
+* and current temperature value can happen while the value is
+* transitioning (metastable), thus causing inappropriate event
+* generation. No spurious event occurs as long as the threshold value
+* stays unchanged. Spurious event can be generated while a thermal
+* alert threshold is modified in
+* CONTROL_BANDGAP_THRESHOLD_MPU/GPU/CORE/DSPEVE/IVA_n.
+*/
+
+ if (TI_BANDGAP_HAS(bgp, ERRATA_813)) {
+ /* Mask t_hot and t_cold events at the IP Level */
+ ctrl = ti_bandgap_readl(bgp, tsr->bgap_mask_ctrl);
+
+ if (hot)
+ ctrl &= ~tsr->mask_hot_mask;
+ else
+ ctrl &= ~tsr->mask_cold_mask;
+
+ ti_bandgap_writel(bgp, ctrl, tsr->bgap_mask_ctrl);
+ }
+
+ /* Write the threshold value */
ti_bandgap_writel(bgp, reg_val, tsr->bgap_threshold);
+ if (TI_BANDGAP_HAS(bgp, ERRATA_813)) {
+ /* Unmask t_hot and t_cold events at the IP Level */
+ ctrl = ti_bandgap_readl(bgp, tsr->bgap_mask_ctrl);
+ if (hot)
+ ctrl |= tsr->mask_hot_mask;
+ else
+ ctrl |= tsr->mask_cold_mask;
+
+ ti_bandgap_writel(bgp, ctrl, tsr->bgap_mask_ctrl);
+ }
+
if (err) {
dev_err(bgp->dev, "failed to reprogram thot threshold\n");
er
[PATCH 0/2] thermal: ti-soc-thermal: Implement work around for Errata i813 and i814
The series implements work arounds for couple of Erratas. Tested the series on OMAP5 and DRA7 Boards. Keerthy (2): thermal: ti-soc-thermal: dra7: Implement Workaround for Errata i814 - Bandgap Temperature read Dtemp can be corrupted thermal: ti-soc-thermal: OMAP5: Implement Workaround for Errata i813 .../thermal/ti-soc-thermal/dra752-thermal-data.c | 3 +- .../thermal/ti-soc-thermal/omap5-thermal-data.c| 3 +- drivers/thermal/ti-soc-thermal/ti-bandgap.c| 78 +- drivers/thermal/ti-soc-thermal/ti-bandgap.h| 6 ++ 4 files changed, 86 insertions(+), 4 deletions(-) -- 1.9.1 -- 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/2] thermal: ti-soc-thermal: OMAP5: Implement Workaround for Errata i813
DESCRIPTION
Spurious Thermal Alert: Talert can happen randomly while the device remains
under the temperature limit
defined for this event to trig. This spurious event is caused by a incorrect
re-synchronization between
clock domains. The comparison between configured threshold and current
temperature value can happen
while the value is transitioning (metastable), thus causing inappropriate event
generation.
No spurious event occurs as long as the threshold value stays unchanged.
Spurious event can be
generated while a thermal alert threshold is modified in
CONTROL_BANDGAP_THRESHOLD_MPU/GPU/CORE/DSPEVE/IVA_n.
WORKAROUND
Spurious event generation can be avoided by performing following sequence when
the threshold is
modified:
1. Mask the hot/cold events at the thermal IP level.
2. Modify Threshold.
3. Unmask the hot/cold events at the thermal IP level.
Signed-off-by: Keerthy
---
.../thermal/ti-soc-thermal/omap5-thermal-data.c| 3 +-
drivers/thermal/ti-soc-thermal/ti-bandgap.c| 41 +-
drivers/thermal/ti-soc-thermal/ti-bandgap.h| 4 ++-
3 files changed, 45 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/ti-soc-thermal/omap5-thermal-data.c
b/drivers/thermal/ti-soc-thermal/omap5-thermal-data.c
index eff0c80..79ff70c 100644
--- a/drivers/thermal/ti-soc-thermal/omap5-thermal-data.c
+++ b/drivers/thermal/ti-soc-thermal/omap5-thermal-data.c
@@ -319,7 +319,8 @@ const struct ti_bandgap_data omap5430_data = {
TI_BANDGAP_FEATURE_FREEZE_BIT |
TI_BANDGAP_FEATURE_TALERT |
TI_BANDGAP_FEATURE_COUNTER_DELAY |
- TI_BANDGAP_FEATURE_HISTORY_BUFFER,
+ TI_BANDGAP_FEATURE_HISTORY_BUFFER |
+ TI_BANDGAP_FEATURE_ERRATA_813,
.fclock_name = "l3instr_ts_gclk_div",
.div_ck_name = "l3instr_ts_gclk_div",
.conv_table = omap5430_adc_to_temp,
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 8fdddb6..08a2155 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -445,7 +445,7 @@ static int ti_bandgap_update_alert_threshold(struct
ti_bandgap *bgp, int id,
{
struct temp_sensor_data *ts_data = bgp->conf->sensors[id].ts_data;
struct temp_sensor_registers *tsr;
- u32 thresh_val, reg_val, t_hot, t_cold;
+ u32 thresh_val, reg_val, t_hot, t_cold, ctrl;
int err = 0;
tsr = bgp->conf->sensors[id].registers;
@@ -477,8 +477,47 @@ static int ti_bandgap_update_alert_threshold(struct
ti_bandgap *bgp, int id,
~(tsr->threshold_thot_mask | tsr->threshold_tcold_mask);
reg_val |= (t_hot << __ffs(tsr->threshold_thot_mask)) |
(t_cold << __ffs(tsr->threshold_tcold_mask));
+
+ /**
+* Errata i813:
+* Spurious Thermal Alert: Talert can happen randomly while the device
+* remains under the temperature limit defined for this event to trig.
+* This spurious event is caused by a incorrect re-synchronization
+* between clock domains. The comparison between configured threshold
+* and current temperature value can happen while the value is
+* transitioning (metastable), thus causing inappropriate event
+* generation. No spurious event occurs as long as the threshold value
+* stays unchanged. Spurious event can be generated while a thermal
+* alert threshold is modified in
+* CONTROL_BANDGAP_THRESHOLD_MPU/GPU/CORE/DSPEVE/IVA_n.
+*/
+
+ if (TI_BANDGAP_HAS(bgp, ERRATA_813)) {
+ /* Mask t_hot and t_cold events at the IP Level */
+ ctrl = ti_bandgap_readl(bgp, tsr->bgap_mask_ctrl);
+
+ if (hot)
+ ctrl &= ~tsr->mask_hot_mask;
+ else
+ ctrl &= ~tsr->mask_cold_mask;
+
+ ti_bandgap_writel(bgp, ctrl, tsr->bgap_mask_ctrl);
+ }
+
+ /* Write the threshold value */
ti_bandgap_writel(bgp, reg_val, tsr->bgap_threshold);
+ if (TI_BANDGAP_HAS(bgp, ERRATA_813)) {
+ /* Unmask t_hot and t_cold events at the IP Level */
+ ctrl = ti_bandgap_readl(bgp, tsr->bgap_mask_ctrl);
+ if (hot)
+ ctrl |= tsr->mask_hot_mask;
+ else
+ ctrl |= tsr->mask_cold_mask;
+
+ ti_bandgap_writel(bgp, ctrl, tsr->bgap_mask_ctrl);
+ }
+
if (err) {
dev_err(bgp->dev, "failed to reprogram thot threshold\n");
err = -EIO;
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
index b2da3fc..0c52f7a 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
@@ -320,7 +320,8 @@ struct ti_temp_sensor {
*
[PATCH 1/2] thermal: ti-soc-thermal: dra7: Implement Workaround for Errata i814 - Bandgap Temperature read Dtemp can be corrupted
Bandgap Temperature read Dtemp can be corrupted
DESCRIPTION
Read accesses to registers listed below can be corrupted due to
incorrect resynchronization between
clock domains.
Read access to registers below can be corrupted :
• CTRL_CORE_DTEMP_MPU/GPU/CORE/DSPEVE/IVA_n (n = 0 to 4)
• CTRL_CORE_TEMP_SENSOR_MPU/GPU/CORE/DSPEVE/IVA_n
WORKAROUND
Multiple reads to CTRL_CORE_TEMP_SENSOR_MPU/GPU/CORE/DSPEVE/IVA[9:0]:
BGAP_DTEMPMPU/GPU/CORE/DSPEVE/IVA is needed to discard false value and
read right value:
1. Perform two successive reads to BGAP_DTEMP bit field.
(a) If read1 returns Val1 and read2 returns Val1, then
right value is Val1.
(b) If read1 returns Val1, read 2 returns Val2, a third
read is needed.
2. Perform third read
(a) If read3 returns Val2 then right value is Val2.
(b) If read3 returns Val3, then right value is Val3.
The above in gist means if val1 and val2 are the same then we can go
ahead with that value
else we need a third read which will be right since synchronization
will be complete by then.
Signed-off-by: Keerthy
---
.../thermal/ti-soc-thermal/dra752-thermal-data.c | 3 +-
drivers/thermal/ti-soc-thermal/ti-bandgap.c| 37 +-
drivers/thermal/ti-soc-thermal/ti-bandgap.h| 4 +++
3 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
b/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
index a492927..58b5c66 100644
--- a/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
+++ b/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
@@ -420,7 +420,8 @@ const struct ti_bandgap_data dra752_data = {
TI_BANDGAP_FEATURE_FREEZE_BIT |
TI_BANDGAP_FEATURE_TALERT |
TI_BANDGAP_FEATURE_COUNTER_DELAY |
- TI_BANDGAP_FEATURE_HISTORY_BUFFER,
+ TI_BANDGAP_FEATURE_HISTORY_BUFFER |
+ TI_BANDGAP_FEATURE_ERRATA_814,
.fclock_name = "l3instr_ts_gclk_div",
.div_ck_name = "l3instr_ts_gclk_div",
.conv_table = dra752_adc_to_temp,
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce..8fdddb6 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -119,6 +119,37 @@ exit:
}
/**
+ * ti_errata814_bandgap_read_temp() - helper function to read dra7 sensor
temperature
+ * @bgp: pointer to ti_bandgap structure
+ * @reg: desired register (offset) to be read
+ *
+ * Function to read dra7 bandgap sensor temperature. This is done separately
+ * so as to workaround the errata "Bandgap Temperature read Dtemp can be
+ * corrupted" - Errata ID: i814".
+ * Read accesses to registers listed below can be corrupted due to incorrect
+ * resynchronization between clock domains.
+ * Read access to registers below can be corrupted :
+ * CTRL_CORE_DTEMP_MPU/GPU/CORE/DSPEVE/IVA_n (n = 0 to 4)
+ * CTRL_CORE_TEMP_SENSOR_MPU/GPU/CORE/DSPEVE/IVA_n
+ *
+ * Return: the register value.
+ */
+static u32 ti_errata814_bandgap_read_temp(struct ti_bandgap *bgp, u32 reg)
+{
+ u32 val1, val2;
+
+ val1 = ti_bandgap_readl(bgp, reg);
+ val2 = ti_bandgap_readl(bgp, reg);
+
+ /* If both times we read the same value then that is right */
+ if (val1 == val2)
+ return val1;
+
+ /* if val1 and val2 are different read it third time */
+ return ti_bandgap_readl(bgp, reg);
+}
+
+/**
* ti_bandgap_read_temp() - helper function to read sensor temperature
* @bgp: pointer to ti_bandgap structure
* @id: bandgap sensor id
@@ -148,7 +179,11 @@ static u32 ti_bandgap_read_temp(struct ti_bandgap *bgp,
int id)
}
/* read temperature */
- temp = ti_bandgap_readl(bgp, reg);
+ if (TI_BANDGAP_HAS(bgp, ERRATA_814))
+ temp = ti_errata814_bandgap_read_temp(bgp, reg);
+ else
+ temp = ti_bandgap_readl(bgp, reg);
+
temp &= tsr->bgap_dtemp_mask;
if (TI_BANDGAP_HAS(bgp, FREEZE_BIT))
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
index b3adf72..b2da3fc 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
@@ -318,6 +318,9 @@ struct ti_temp_sensor {
* TI_BANDGAP_FEATURE_HISTORY_BUFFER - used when the bandgap device features
* a history buffer of temperatures.
*
+ * TI_BANDGAP_FEATURE_ERRATA_814 - used to workaorund when the bandgap device
+ * has Errata 814
+ *
* TI_BANDGAP_HAS(b, f) - macro to check if a bandgap device is capable of a
* specific feature (above) or not. Return non-zero, if yes.
*/
@@ -331,6 +334,7 @@ struct ti_te
Re: [RFC][PATCH v2 00/13] USB: OTG/DRD Core functionality
On 22/04/15 12:22, Peter Chen wrote:
> On Wed, Apr 22, 2015 at 10:33:24AM +0300, Roger Quadros wrote:
>> On 22/04/15 05:17, Peter Chen wrote:
>>> On Tue, Apr 21, 2015 at 10:34:01AM +0300, Roger Quadros wrote:
On 21/04/15 09:04, Peter Chen wrote:
>
>>
>> On 20/04/15 06:05, Peter Chen wrote:
>>> On Tue, Apr 14, 2015 at 01:41:47PM +0300, Roger Quadros wrote:
This is an attempt to centralize OTG/Dual-role functionality in the
kernel.
As of now I've got Dual-role functionality working pretty reliably on
dra7-evm. xhci side of things for OTG/DRD use are fixed in
http://thread.gmane.org/gmane.linux.kernel/1923161
>>>
>>> Hi Roger,
>>>
>>> Currently, there are two main problems for DRD/OTG framework.
>>>
>>> - For multi-platform supports, we may define CONFIG_USB_OTG, but the
>>> gadget should not add its otg descriptor to its configuration
>>> descriptors if it does not support one of otg features (SRP/HNP/ADP).
>>> Macpaul Lin's patch set [1] is the right way to do it.
>>
>> Agreed. That check (whether OTG descriptor can be added and which version
>> of it) has to be done at runtime and it must be added only if hardware
>> supports
>> OTG _and_ kernel OTG support is enabled.
>>
>
> Ok, let's put this patch set in mainline first, since your patch set may
> need some
> information from it.
>
>>> - We are lack of framework to handle OTG (DRD) switch, it is great you
>>> are designing it. The main problem for this framework is how to handle
>>> DRD/OTG FSM unify. My thought is we add two paths for them separate.
>>> For easy, I suggest if the platform supports one of otg features, then
>>> it goes to fully otg fsm, else it goes to simply otg fsm (like your
>>> drd fsm). If you agree with it too, you may not need to add another
>> "dr_mode"
>>> value.
>>
>> It would be nice that way but unfortunately it does't work in all cases.
>> e.g. What if the SoC itself supports all OTG features but the board is
>> not
>> designed for OTG. Or the product designer simply is not interested in
>> full OTG
>> support but just dual-role. So we need some flexibility for the device
>> tree/platform-data to specify that. This is where a new "dr_mode" ==
>> "dual-
>> role" is needed.
>>
>
> Since "dr_mode" has been widely used now, if we add a new property for
> it, we
> need to change all drivers.
>
> Your OTG/DRD framework needs to (partial) use otg fsm, and we will not
> teach old
> driver to use it since there are some driver related stuffs.
fair enough. Let's not change dr_mode then and decide based on other
parameters.
>
> SRP/HNP/ADP support can be board level capabilities, and we may consider
> the
> otg device which does not support otg fsm (hardware finishes fsm). So I
> suggest
> we have below properties at dts:
>
> - otg-support /* fully otg support */
> - otg-fsm-support /* fully otg fsm support */
what is the difference between otg-support and otg-fsm-support?
>>>
>>> Like I mentioned at above, the hardware finishes HNP/SRP which does not
>>> use otg fsm code (usb-otg-fsm.c), most of legacy otg platforms (musb?)
>>> use this way, for these platforms, only need to set otg-support = 1
>>
>> So dr_mode = "otg" _and_ otg-support = 1?
>>
>
> Yes
>
>> Again wouldn't this involve changes to dts for musb like platforms
>> supporting full OTG?
>>
>> Instead we could add a new field saying otg-fsm-type
>> "otg-hw", "otg-sw", "drd-sw"
>>
>> If the field is absent it defaults to "otg-hw".
>> This also means we don't need otg-fsm-support flag.
>>
>
> Yes, that's we doesn't need to change for old platforms, but
> we keep our default value as small possibilities, most of current
> platforms are only drd platform, it is hard choice.
>
> My original thought was nothing need to add at dts for drd device.
>
>> Now the pseudo-code to decide fsm is
>>
>> if (dr_mode == "otg" && CONFIG_USB_OTG)
>> if (otg-fsm-type == "otg-sw") {
>> if (CONFIG_USB_OTG_FSM)
>> full otg fsm support via sw
>> else
>> error "CONFIG_USB_OTG_FSM" not set
>> } else if (otg-fsm-type == "drd-sw") {
>> dual role fsm support
>> } else {
>> full otg support via hw
>> }
>>
>> if (otg-fsm-type == "otg
>> else
>> error "CONFIG_USB_OTG" not set
>
> So we will have a separate drd fsm file, and the CONFIG_USB_OTG
> and CONFIG_USB_OTG_FSM are not needed to be defined, right?
>
for drd case CONFIG_USB_OTG_FSM is definitely not needed.
I'm not sure if we can operate dual-role without CONFIG_USB_OTG.
I was thinking of combining the OTG core functionality
(drivers/usb/common/usb-otg.c)
with CONFIG_USB_OTG.
>>
>>>
>>> For pl
Re: [PATCH V2] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 21/04/2015 at 20:59:15 -0500, Nishanth Menon wrote : > >> Why is that so? when set alarm is requested for time X, you want > >> interrupt at time X, not an interrupt for previous configured RTC > >> alarm time! > >> > > > > You expect at least an interrupt. > > And you will get an interrupt if the event occurs before the i2c burst > starts. Once the i2cburst does start, you are committing to the new time. > You mean that even if ALM0EN is set after ALM0IF was set to 1, it will trigger the interrupt? I had a look at the MFP output block diagram would let me think that this is the case. I was thinking otherwise before. If that is so, then indeed, your patch is OK. My concern was about the time between ds1307->write_block_data() and i2c_smbus_write_byte_data() which actually calls cond_sched(). I fully agree that your patch doesn't change the behaviour for the other cases you presented and further clean up is to be done in a separate set of patches. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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: Add calls for pinctrl state select
On 22.04.2015 12:28, Wolfram Sang wrote: > I assume you have a different kernel config where something is enabled > which includes the pinctrl-stuff in another include which is included > by these drivers. Although, my .config was arm-allyesconfig. Can you > send yours? Sure. See below. cat .config | grep -v "#" | sed '/^$/d' | sort (Or do you prefer it attached?) CONFIG_ADVISE_SYSCALLS=y CONFIG_AEABI=y CONFIG_AIO=y CONFIG_ALIGNMENT_TRAP=y CONFIG_ALLOW_DEV_COREDUMP=y CONFIG_AM335X_CONTROL_USB=y CONFIG_AM335X_PHY_USB=y CONFIG_ANON_INODES=y CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y CONFIG_ARCH_HAS_BANDGAP=y CONFIG_ARCH_HAS_ELF_RANDOMIZE=y CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y CONFIG_ARCH_HAS_SG_CHAIN=y CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y CONFIG_ARCH_MULTIPLATFORM=y CONFIG_ARCH_MULTI_V6_V7=y CONFIG_ARCH_MULTI_V7=y CONFIG_ARCH_NR_GPIO=0 CONFIG_ARCH_OMAP2PLUS_TYPICAL=y CONFIG_ARCH_OMAP2PLUS=y CONFIG_ARCH_OMAP3=y CONFIG_ARCH_OMAP=y CONFIG_ARCH_REQUIRE_GPIOLIB=y CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_USE_BUILTIN_BSWAP=y CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA=y CONFIG_ARCH_VEXPRESS=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y CONFIG_ARM_AMBA=y CONFIG_ARM_CPU_SUSPEND=y CONFIG_ARM_DMA_MEM_BUFFERABLE=y CONFIG_ARM_ERRATA_430973=y CONFIG_ARM_ERRATA_720789=y CONFIG_ARM_GIC=y CONFIG_ARM_GLOBAL_TIMER=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_ARM_L1_CACHE_SHIFT=6 CONFIG_ARM_L1_CACHE_SHIFT_6=y CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_ARM_THUMBEE=y CONFIG_ARM_THUMB=y CONFIG_ARM_TIMER_SP804=y CONFIG_ARM_UNWIND=y CONFIG_ARM_VIRT_EXT=y CONFIG_ARM=y CONFIG_ASSOCIATIVE_ARRAY=y CONFIG_AT803X_PHY=y CONFIG_ATAGS_PROC=y CONFIG_ATAGS=y CONFIG_AUTO_ZRELADDR=y CONFIG_AVERAGE=y CONFIG_BASE_SMALL=1 CONFIG_BCH=y CONFIG_BCMA_POSSIBLE=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_BINFMT_SCRIPT=y CONFIG_BITREVERSE=y CONFIG_BLK_DEV_BSGLIB=y CONFIG_BLK_DEV_BSG=y CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV=y CONFIG_BLOCK=y CONFIG_BOUNCE=y CONFIG_BPF=y CONFIG_BQL=y CONFIG_BROKEN_ON_SMP=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BUG=y CONFIG_BUILD_BIN2C=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_CC_STACKPROTECTOR_NONE=y CONFIG_CFG80211_DEBUGFS=y CONFIG_CFG80211_DEFAULT_PS=y CONFIG_CFG80211_WEXT=y CONFIG_CFG80211=y CONFIG_CGROUPS=y CONFIG_CLKDEV_LOOKUP=y CONFIG_CLK_SP810=y CONFIG_CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK=y CONFIG_CLKSRC_MMIO=y CONFIG_CLKSRC_OF=y CONFIG_CLKSRC_VERSATILE=y CONFIG_CLK_VEXPRESS_OSC=y CONFIG_CLONE_BACKWARDS=y CONFIG_CMDLINE="" CONFIG_COMMON_CLK_SI5351=y CONFIG_COMMON_CLK_VERSATILE=y CONFIG_COMMON_CLK=y CONFIG_COMPAT_BRK=y CONFIG_CONFIGFS_FS=y CONFIG_CONNECTOR=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y CONFIG_COREDUMP=y CONFIG_CPU_32v6K=y CONFIG_CPU_32v7=y CONFIG_CPU_ABRT_EV7=y CONFIG_CPU_CACHE_V7=y CONFIG_CPU_CACHE_VIPT=y CONFIG_CPU_COPY_V6=y CONFIG_CPU_CP15_MMU=y CONFIG_CPU_CP15=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_COMMON=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ=y CONFIG_CPU_HAS_ASID=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y CONFIG_CPU_IDLE=y CONFIG_CPU_PABRT_V7=y CONFIG_CPU_PM=y CONFIG_CPU_TLB_V7=y CONFIG_CPU_V7=y CONFIG_CRAMFS=y CONFIG_CRC16=y CONFIG_CRC32_SLICEBY8=y CONFIG_CRC32=y CONFIG_CRC7=y CONFIG_CRC_CCITT=y CONFIG_CRC_ITU_T=y CONFIG_CRC_T10DIF=y CONFIG_CROSS_COMPILE="" CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_AEAD=y CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ARC4=y CONFIG_CRYPTO_AUTHENC=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_CRCT10DIF=y CONFIG_CRYPTO_DEFLATE=y CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_HW=y CONFIG_CRYPTO_LZO=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=y CONFIG_CRYPTO_PCOMP2=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO=y CONFIG_DCACHE_WORD_ACCESS=y CONFIG_DEBUG_FS=y CONFIG_DEBUG_GPIO=y CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S" CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_PREEMPT=y CONFIG_DEBUG_SECTION_MISMATCH=y CONFIG_DEBUG_SPINLOCK=y CONFIG_DEFAULT_CFQ=y CONFIG_DEFAULT_CUBIC=y CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_DEFAULT_SECURITY="" CONFIG_DEFAULT_SECURITY_DAC=
Re: [PATCH] omap: i2c: Add calls for pinctrl state select
> You are right, the include is missing. I just reapplied the patch, > compiled and interestingly enough, I don't get any compile errors. (?) I assume you have a different kernel config where something is enabled which includes the pinctrl-stuff in another include which is included by these drivers. Although, my .config was arm-allyesconfig. Can you send yours? signature.asc Description: Digital signature
Re: [RFC][PATCH v2 00/13] USB: OTG/DRD Core functionality
On Wed, Apr 22, 2015 at 10:33:24AM +0300, Roger Quadros wrote:
> On 22/04/15 05:17, Peter Chen wrote:
> > On Tue, Apr 21, 2015 at 10:34:01AM +0300, Roger Quadros wrote:
> >> On 21/04/15 09:04, Peter Chen wrote:
> >>>
>
> On 20/04/15 06:05, Peter Chen wrote:
> > On Tue, Apr 14, 2015 at 01:41:47PM +0300, Roger Quadros wrote:
> >> This is an attempt to centralize OTG/Dual-role functionality in the
> >> kernel.
> >> As of now I've got Dual-role functionality working pretty reliably on
> >> dra7-evm. xhci side of things for OTG/DRD use are fixed in
> >> http://thread.gmane.org/gmane.linux.kernel/1923161
> >
> > Hi Roger,
> >
> > Currently, there are two main problems for DRD/OTG framework.
> >
> > - For multi-platform supports, we may define CONFIG_USB_OTG, but the
> > gadget should not add its otg descriptor to its configuration
> > descriptors if it does not support one of otg features (SRP/HNP/ADP).
> > Macpaul Lin's patch set [1] is the right way to do it.
>
> Agreed. That check (whether OTG descriptor can be added and which version
> of it) has to be done at runtime and it must be added only if hardware
> supports
> OTG _and_ kernel OTG support is enabled.
>
> >>>
> >>> Ok, let's put this patch set in mainline first, since your patch set may
> >>> need some
> >>> information from it.
> >>>
> > - We are lack of framework to handle OTG (DRD) switch, it is great you
> > are designing it. The main problem for this framework is how to handle
> > DRD/OTG FSM unify. My thought is we add two paths for them separate.
> > For easy, I suggest if the platform supports one of otg features, then
> > it goes to fully otg fsm, else it goes to simply otg fsm (like your
> > drd fsm). If you agree with it too, you may not need to add another
> "dr_mode"
> > value.
>
> It would be nice that way but unfortunately it does't work in all cases.
> e.g. What if the SoC itself supports all OTG features but the board is
> not
> designed for OTG. Or the product designer simply is not interested in
> full OTG
> support but just dual-role. So we need some flexibility for the device
> tree/platform-data to specify that. This is where a new "dr_mode" ==
> "dual-
> role" is needed.
>
> >>>
> >>> Since "dr_mode" has been widely used now, if we add a new property for
> >>> it, we
> >>> need to change all drivers.
> >>>
> >>> Your OTG/DRD framework needs to (partial) use otg fsm, and we will not
> >>> teach old
> >>> driver to use it since there are some driver related stuffs.
> >>
> >> fair enough. Let's not change dr_mode then and decide based on other
> >> parameters.
> >>
> >>>
> >>> SRP/HNP/ADP support can be board level capabilities, and we may consider
> >>> the
> >>> otg device which does not support otg fsm (hardware finishes fsm). So I
> >>> suggest
> >>> we have below properties at dts:
> >>>
> >>> - otg-support /* fully otg support */
> >>> - otg-fsm-support /* fully otg fsm support */
> >>
> >> what is the difference between otg-support and otg-fsm-support?
> >
> > Like I mentioned at above, the hardware finishes HNP/SRP which does not
> > use otg fsm code (usb-otg-fsm.c), most of legacy otg platforms (musb?)
> > use this way, for these platforms, only need to set otg-support = 1
>
> So dr_mode = "otg" _and_ otg-support = 1?
>
Yes
> Again wouldn't this involve changes to dts for musb like platforms
> supporting full OTG?
>
> Instead we could add a new field saying otg-fsm-type
> "otg-hw", "otg-sw", "drd-sw"
>
> If the field is absent it defaults to "otg-hw".
> This also means we don't need otg-fsm-support flag.
>
Yes, that's we doesn't need to change for old platforms, but
we keep our default value as small possibilities, most of current
platforms are only drd platform, it is hard choice.
My original thought was nothing need to add at dts for drd device.
> Now the pseudo-code to decide fsm is
>
> if (dr_mode == "otg" && CONFIG_USB_OTG)
> if (otg-fsm-type == "otg-sw") {
> if (CONFIG_USB_OTG_FSM)
> full otg fsm support via sw
> else
> error "CONFIG_USB_OTG_FSM" not set
> } else if (otg-fsm-type == "drd-sw") {
> dual role fsm support
> } else {
> full otg support via hw
> }
>
> if (otg-fsm-type == "otg
> else
> error "CONFIG_USB_OTG" not set
So we will have a separate drd fsm file, and the CONFIG_USB_OTG
and CONFIG_USB_OTG_FSM are not needed to be defined, right?
>
> >
> > For platforms which software finishes HNP/SRP using otg fsm code, need
> > to set both flags.
> >
> > For platforms which only do role switch through id pin, do not need to
> > set both.
> >
>
> OK. I get it now.
>
> >>
> >>> - otg-ver /* eh & otg supplement version */
> >>
> >> we can get otg version from the
[PATCH v2] omap: i2c: Add calls for pinctrl state select
From: Pascal Huerst This adds calls to pinctrl subsystem in order to switch pin states on suspend/resume if you provide a "sleep" state in DT. Signed-off-by: Pascal Huerst --- drivers/i2c/busses/i2c-omap.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 0e89419..8261941 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -38,6 +38,7 @@ #include #include #include +#include /* I2C controller revisions */ #define OMAP_I2C_OMAP1_REV_2 0x20 @@ -1423,6 +1424,8 @@ static int omap_i2c_runtime_suspend(struct device *dev) omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); } + pinctrl_pm_select_sleep_state(dev); + return 0; } @@ -1431,6 +1434,8 @@ static int omap_i2c_runtime_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); + pinctrl_pm_select_default_state(dev); + if (!_dev->regs) return 0; -- 2.1.0 -- 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: Add calls for pinctrl state select
Hey Wolfram, On 22.04.2015 10:12, Wolfram Sang wrote: > On Fri, Apr 17, 2015 at 05:07:57PM +0200, pascal.hue...@gmail.com wrote: >> From: Pascal Huerst >> >> This adds calls to pinctrl subsystem in order to switch pin states >> on suspend/resume if you provide a "sleep" state in DT. >> >> Signed-off-by: Pascal Huerst > > ? Don't you get a build error? I do. Rightfully, I'd think, there is no > pinctrl-include. You are right, the include is missing. I just reapplied the patch, compiled and interestingly enough, I don't get any compile errors. (?) Some further checks revealed, that the include is also missing in drivers/i2c/busses/i2c-st.c - which I used to get the idea on how to use these calls. I'm using a buildroot toolchain: gcc version 4.9.2 (Buildroot 2014.11-00023-g60d7a19-dirty) Do you have any idea on where these differences are coming from? In any case, the include belongs there, so I will resend that patch. regards pascal -- 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: Add calls for pinctrl state select
On Fri, Apr 17, 2015 at 05:07:57PM +0200, pascal.hue...@gmail.com wrote: > From: Pascal Huerst > > This adds calls to pinctrl subsystem in order to switch pin states > on suspend/resume if you provide a "sleep" state in DT. > > Signed-off-by: Pascal Huerst ? Don't you get a build error? I do. Rightfully, I'd think, there is no pinctrl-include. signature.asc Description: Digital signature
Re: [PATCH v5 0/8] dmaengine/dra7x: DMA router (crossbar support)
On 04/09/2015 12:35 PM, Peter Ujfalusi wrote: > Vinod: is it OK if I send the Documnetation/dmanegine/ update a bit later when > I have finished it? > > Changes since v4: > - Comments from Maxime Ripard addressed: > - long line fixed in of-dma.c > - node leaks has been fixed in ti-dma-crossbar > - Using devm_ioremap_resource() in ti-dma-crossbar > - u16 casting has been addressed > - Router drivers are expected to return with ERR_PTR in case their > of_dma_route_allocate() callback fails. Are there more comments I need to address with this series? Thanks, Péter > Changes since v3: > - Comments from Russell: > - Warnings removed in case of non DT boot when taking the DMA request number > - Reduced the number of channels presented to DMAengine > - removed the dma_sig parameter from omap_dma_chan_init() > - Comments from Arnd: > - dma-device property renamed to dma-masters > - Allow list of phandes in dma-masters > > Changes since v2: > - not using regmap for the TI crossbar driver. > > Changes since v1: > - Comments from Russell King and Paul Bolle addressed: > - Use the added defined in the omap-dma changes > - MODULE_* removed from the ti-dma-crossbar driver. > - DMA router documentation: do not limit the #dma-cells to be the same as the > dma controller's #dma-cells. It might be possible to have a router which > needs > more information than the DMA controller (direct request pairing for > example) > - Use defines in the ti-dma-crossbar driver > - Binding document for the ti-dma-crossbar driver > > Intro mail from v1: > > The series adds support for DMA router type of devices. They are used in SoCs > which has more peripherals with DMA request lines than the DMA controller can > handle. > The router itself is not part of the DMA controller and it's operation should > be > transparent (as it is in the HW) for the SW stack. > > This series takes into accound the comments Sricharan received for his version > of the crossbar driver: > https://lkml.org/lkml/2014/3/7/199 > > This implementation is not tied to any DMA driver so it is possible to use the > framework by other vendors, also ACPI version of binding can be easy enough to > be added. > > Regards, > Peter > --- > Peter Ujfalusi (8): > dmaengine: of_dma: Support for DMA routers > Documentation: devicetree: dma: Binding documentation for TI DMA > crossbar > dmaengine: Add driver for TI DMA crossbar on DRA7x > dmaengine: omap-dma: Use defines for dma channels and request count > dmaengine: omap-dma: Take DMA request number from DT if it is > available > dmaengine: omap-dma: Remove mapping between virtual channels and > requests > dmaengine: omap-dma: Reduce the number of virtual channels > ARM: DTS: dra7x: Integrate sDMA crossbar > > Documentation/devicetree/bindings/dma/dma.txt | 28 +++ > .../devicetree/bindings/dma/ti-dma-crossbar.txt| 52 ++ > arch/arm/boot/dts/dra7.dtsi| 57 --- > drivers/dma/Kconfig| 4 + > drivers/dma/Makefile | 1 + > drivers/dma/dmaengine.c| 7 + > drivers/dma/of-dma.c | 89 ++ > drivers/dma/omap-dma.c | 29 +++- > drivers/dma/ti-dma-crossbar.c | 188 > + > include/linux/dmaengine.h | 17 ++ > include/linux/of_dma.h | 21 +++ > 11 files changed, 463 insertions(+), 30 deletions(-) > create mode 100644 Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt > create mode 100644 drivers/dma/ti-dma-crossbar.c > -- 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] dmaengine: omap-dma: Add support for memcpy
The sDMA controller is capable of performing memory copy operation. It need
to be configured to software triggered mode and without HW synchronization.
The sDMA can copy data which is aligned to 8, 16 or 32 bits.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/omap-dma.c | 51 --
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 36e6a299af5c..1dfc71c90123 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -366,7 +366,7 @@ static void omap_dma_start_sg(struct omap_chan *c, struct
omap_desc *d,
struct omap_sg *sg = d->sg + idx;
unsigned cxsa, cxei, cxfi;
- if (d->dir == DMA_DEV_TO_MEM) {
+ if (d->dir == DMA_DEV_TO_MEM || d->dir == DMA_MEM_TO_MEM) {
cxsa = CDSA;
cxei = CDEI;
cxfi = CDFI;
@@ -412,7 +412,7 @@ static void omap_dma_start_desc(struct omap_chan *c)
if (dma_omap1())
omap_dma_chan_write(c, CCR2, d->ccr >> 16);
- if (d->dir == DMA_DEV_TO_MEM) {
+ if (d->dir == DMA_DEV_TO_MEM || d->dir == DMA_MEM_TO_MEM) {
cxsa = CSSA;
cxei = CSEI;
cxfi = CSFI;
@@ -957,6 +957,51 @@ static struct dma_async_tx_descriptor
*omap_dma_prep_dma_cyclic(
return vchan_tx_prep(&c->vc, &d->vd, flags);
}
+static struct dma_async_tx_descriptor *omap_dma_prep_dma_memcpy(
+ struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
+ size_t len, unsigned long tx_flags)
+{
+ struct omap_chan *c = to_omap_dma_chan(chan);
+ struct omap_desc *d;
+ uint8_t data_type;
+
+ d = kzalloc(sizeof(*d) + sizeof(d->sg[0]), GFP_ATOMIC);
+ if (!d)
+ return NULL;
+
+ data_type = __ffs((src | dest | len));
+ if (data_type > CSDP_DATA_TYPE_32)
+ data_type = CSDP_DATA_TYPE_32;
+
+ d->dir = DMA_MEM_TO_MEM;
+ d->dev_addr = src;
+ d->fi = 0;
+ d->es = data_type;
+ d->sg[0].en = len / BIT(data_type);
+ d->sg[0].fn = 1;
+ d->sg[0].addr = dest;
+ d->sglen = 1;
+ d->ccr = c->ccr;
+ d->ccr |= CCR_DST_AMODE_POSTINC | CCR_SRC_AMODE_POSTINC;
+
+ d->cicr = CICR_DROP_IE;
+ if (tx_flags & DMA_PREP_INTERRUPT)
+ d->cicr |= CICR_FRAME_IE;
+
+ d->csdp = data_type;
+
+ if (dma_omap1()) {
+ d->cicr |= CICR_TOUT_IE;
+ d->csdp |= CSDP_DST_PORT_EMIFF | CSDP_SRC_PORT_EMIFF;
+ } else {
+ d->csdp |= CSDP_DST_PACKED | CSDP_SRC_PACKED;
+ d->cicr |= CICR_MISALIGNED_ERR_IE | CICR_TRANS_ERR_IE;
+ d->csdp |= CSDP_DST_BURST_64 | CSDP_SRC_BURST_64;
+ }
+
+ return vchan_tx_prep(&c->vc, &d->vd, tx_flags);
+}
+
static int omap_dma_slave_config(struct dma_chan *chan, struct
dma_slave_config *cfg)
{
struct omap_chan *c = to_omap_dma_chan(chan);
@@ -1102,12 +1147,14 @@ static int omap_dma_probe(struct platform_device *pdev)
dma_cap_set(DMA_SLAVE, od->ddev.cap_mask);
dma_cap_set(DMA_CYCLIC, od->ddev.cap_mask);
+ dma_cap_set(DMA_MEMCPY, od->ddev.cap_mask);
od->ddev.device_alloc_chan_resources = omap_dma_alloc_chan_resources;
od->ddev.device_free_chan_resources = omap_dma_free_chan_resources;
od->ddev.device_tx_status = omap_dma_tx_status;
od->ddev.device_issue_pending = omap_dma_issue_pending;
od->ddev.device_prep_slave_sg = omap_dma_prep_slave_sg;
od->ddev.device_prep_dma_cyclic = omap_dma_prep_dma_cyclic;
+ od->ddev.device_prep_dma_memcpy = omap_dma_prep_dma_memcpy;
od->ddev.device_config = omap_dma_slave_config;
od->ddev.device_pause = omap_dma_pause;
od->ddev.device_resume = omap_dma_resume;
--
2.3.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: [RFC][PATCH v2 00/13] USB: OTG/DRD Core functionality
On 22/04/15 05:17, Peter Chen wrote:
> On Tue, Apr 21, 2015 at 10:34:01AM +0300, Roger Quadros wrote:
>> On 21/04/15 09:04, Peter Chen wrote:
>>>
On 20/04/15 06:05, Peter Chen wrote:
> On Tue, Apr 14, 2015 at 01:41:47PM +0300, Roger Quadros wrote:
>> This is an attempt to centralize OTG/Dual-role functionality in the
>> kernel.
>> As of now I've got Dual-role functionality working pretty reliably on
>> dra7-evm. xhci side of things for OTG/DRD use are fixed in
>> http://thread.gmane.org/gmane.linux.kernel/1923161
>
> Hi Roger,
>
> Currently, there are two main problems for DRD/OTG framework.
>
> - For multi-platform supports, we may define CONFIG_USB_OTG, but the
> gadget should not add its otg descriptor to its configuration
> descriptors if it does not support one of otg features (SRP/HNP/ADP).
> Macpaul Lin's patch set [1] is the right way to do it.
Agreed. That check (whether OTG descriptor can be added and which version
of it) has to be done at runtime and it must be added only if hardware
supports
OTG _and_ kernel OTG support is enabled.
>>>
>>> Ok, let's put this patch set in mainline first, since your patch set may
>>> need some
>>> information from it.
>>>
> - We are lack of framework to handle OTG (DRD) switch, it is great you
> are designing it. The main problem for this framework is how to handle
> DRD/OTG FSM unify. My thought is we add two paths for them separate.
> For easy, I suggest if the platform supports one of otg features, then
> it goes to fully otg fsm, else it goes to simply otg fsm (like your
> drd fsm). If you agree with it too, you may not need to add another
"dr_mode"
> value.
It would be nice that way but unfortunately it does't work in all cases.
e.g. What if the SoC itself supports all OTG features but the board is not
designed for OTG. Or the product designer simply is not interested in full
OTG
support but just dual-role. So we need some flexibility for the device
tree/platform-data to specify that. This is where a new "dr_mode" == "dual-
role" is needed.
>>>
>>> Since "dr_mode" has been widely used now, if we add a new property for it,
>>> we
>>> need to change all drivers.
>>>
>>> Your OTG/DRD framework needs to (partial) use otg fsm, and we will not
>>> teach old
>>> driver to use it since there are some driver related stuffs.
>>
>> fair enough. Let's not change dr_mode then and decide based on other
>> parameters.
>>
>>>
>>> SRP/HNP/ADP support can be board level capabilities, and we may consider the
>>> otg device which does not support otg fsm (hardware finishes fsm). So I
>>> suggest
>>> we have below properties at dts:
>>>
>>> - otg-support /* fully otg support */
>>> - otg-fsm-support /* fully otg fsm support */
>>
>> what is the difference between otg-support and otg-fsm-support?
>
> Like I mentioned at above, the hardware finishes HNP/SRP which does not
> use otg fsm code (usb-otg-fsm.c), most of legacy otg platforms (musb?)
> use this way, for these platforms, only need to set otg-support = 1
So dr_mode = "otg" _and_ otg-support = 1?
Again wouldn't this involve changes to dts for musb like platforms
supporting full OTG?
Instead we could add a new field saying otg-fsm-type
"otg-hw", "otg-sw", "drd-sw"
If the field is absent it defaults to "otg-hw".
This also means we don't need otg-fsm-support flag.
Now the pseudo-code to decide fsm is
if (dr_mode == "otg" && CONFIG_USB_OTG)
if (otg-fsm-type == "otg-sw") {
if (CONFIG_USB_OTG_FSM)
full otg fsm support via sw
else
error "CONFIG_USB_OTG_FSM" not set
} else if (otg-fsm-type == "drd-sw") {
dual role fsm support
} else {
full otg support via hw
}
if (otg-fsm-type == "otg
else
error "CONFIG_USB_OTG" not set
>
> For platforms which software finishes HNP/SRP using otg fsm code, need
> to set both flags.
>
> For platforms which only do role switch through id pin, do not need to
> set both.
>
OK. I get it now.
>>
>>> - otg-ver /* eh & otg supplement version */
>>
>> we can get otg version from the OTG controller. What exactly is the
>> otg-ver in dts for?
>
> Since most of otg stuffs are software's, eg, for otg descriptor, we will
> only use otg 2.0 descriptor when both CONFIG_USB_OTG20 and otg-ver = 20
> are set.
CONFIG_USB_OTG20 is redundant now. Plus I mentioned in the respective thread
that it is not suitable for booting single image on different platforms.
As of now I can see 2 inputs regarding otg-ver
- One comes from otg-ver DT property or platform data.
- Second that may come from OTG controller registers. e.g. It might support
OTG v3.0 but system designer wants to limit to OTG v2.0 via otg-ver.
Controller driver can decide among the 2 and set the appro
