Re: [PATCH v2] security: device_cgroup: fix RCU lockdep splat
On Wed, Sep 2, 2015 at 8:14 PM, Paul E. McKenneywrote: > On Wed, Sep 02, 2015 at 12:24:50PM -0400, Tejun Heo wrote: >> cc'ing Paul. >> >> On Wed, Sep 02, 2015 at 08:12:28AM -0500, Felipe Balbi wrote: >> > while booting AM437x device, the following splat >> > triggered: >> > >> > [ 12.005238] === >> > [ 12.009749] [ INFO: suspicious RCU usage. ] >> > [ 12.014116] 4.2.0-next-20150831 #1154 Not tainted >> > [ 12.019050] --- >> > [ 12.023408] security/device_cgroup.c:405 device_cgroup:verify_new_ex >> > called without proper synchronization! >> ... >> > [ 12.128326] [] (verify_new_ex) from [] >> > (devcgroup_access_write+0x374/0x658) >> > [ 12.137426] [] (devcgroup_access_write) from [] >> > (cgroup_file_write+0x28/0x1bc) >> > [ 12.146796] [] (cgroup_file_write) from [] >> > (kernfs_fop_write+0xc0/0x1b8) >> > [ 12.155620] [] (kernfs_fop_write) from [] >> > (__vfs_write+0x1c/0xd8) >> > [ 12.163783] [] (__vfs_write) from [] >> > (vfs_write+0x90/0x16c) >> > [ 12.171426] [] (vfs_write) from [] >> > (SyS_write+0x44/0x9c) >> > [ 12.178806] [] (SyS_write) from [] >> > (ret_fast_syscall+0x0/0x1c) >> >> This shouldn't be happening because devcgroup_access_write() always >> grabs devcgroup_mutex. Looking at the log, the culprit seems to be >> f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to >> RCU_LOCKDEP_WARN()"). It missed the bang for the second test while >> inverting it, so adding rcu_read_lock() isn't the right fix here. >> >> Paul, can you please fix it? > > Gah! Please see below. > > Thanx, Paul > > > > security/device_cgroup: Fix RCU_LOCKDEP_WARN() condition > > f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()") > introduced a bug by incorrectly inverting the condition when moving from > rcu_lockdep_assert() to RCU_LOCKDEP_WARN(). This commit therefore fixes > the inversion. > > Reported-by: Felipe Balbi > Reported-by: Tejun Heo > Signed-off-by: Paul E. McKenney > Cc: Serge Hallyn Just tested this patch without Felipe's previous version on all my machines. The splat is indeed gone. Tested-by: Josh Boyer josh > > diff --git a/security/device_cgroup.c b/security/device_cgroup.c > index 73455089feef..03c1652c9a1f 100644 > --- a/security/device_cgroup.c > +++ b/security/device_cgroup.c > @@ -401,7 +401,7 @@ static bool verify_new_ex(struct dev_cgroup *dev_cgroup, > bool match = false; > > RCU_LOCKDEP_WARN(!rcu_read_lock_held() && > -lockdep_is_held(_mutex), > +!lockdep_is_held(_mutex), > "device_cgroup:verify_new_ex called without proper > synchronization"); > > if (dev_cgroup->behavior == DEVCG_DEFAULT_ALLOW) { > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 8/9] usb: dwc3: core: Prevent otg events from disabling themselves
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/15 17:47, Felipe Balbi wrote: > On Wed, Sep 02, 2015 at 05:24:23PM +0300, Roger Quadros wrote: >> There is a race happening during dwc3_drd_init() that causes >> otg events to get disabled. This is what happens. >> >> dwc3_otg_irq() happens immediately when PRTCAP is set to OTG, >> even though OEVTEN is 0. This is because BIT 31 IRQ of >> OEVT can't be disabled by OEVTEN. >> We configure OEVTEN in dwc3_otg_init() but dwc3_otg_irq() has >> already saved OEVTEN as 0 into dwc->oevten. So finally when >> dwc3_irq_thread_irq() is called we save 0 into OEVTEN >> thus disabling OTG irqs forever. >> >> We fix this by disabling IRQs when configuring OEVTEN in >> dwc3_otg_init(). >> >> Signed-off-by: Roger Quadros> > can't you just merge this patch into the one which introduced the bug to > start with ? Yes, I'll do that. > >> --- >> drivers/usb/dwc3/core.c | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c >> index 684010c..654aebf 100644 >> --- a/drivers/usb/dwc3/core.c >> +++ b/drivers/usb/dwc3/core.c >> @@ -921,6 +921,7 @@ static int dwc3_drd_init(struct dwc3 *dwc) >> int ret, id, vbus; >> struct usb_otg_caps *otgcaps = >otg_config.otg_caps; >> u32 reg; >> +unsigned long flags; >> >> otgcaps->otg_rev = 0; >> otgcaps->hnp_support = false; >> @@ -993,6 +994,8 @@ try_otg_core: >> goto error; >> } >> >> +spin_lock_irqsave(>lock, flags); >> + >> /* we need to set OTG to get events from OTG core */ >> dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG); >> /* GUSB2PHYCFG0.SusPHY=0 */ >> @@ -1018,6 +1021,8 @@ try_otg_core: >> /* OCTL.PeriMode = 1 */ >> dwc3_writel(dwc->regs, DWC3_OCTL, DWC3_OCTL_PERIMODE); >> >> +spin_unlock_irqrestore(>lock, flags); >> + >> dwc3_otg_fsm_sync(dwc); >> usb_otg_sync_inputs(dwc->fsm); >> >> -- >> 2.1.4 >> > - -- cheers, - -roger -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV6FEnAAoJENJaa9O+djCTSjgQALL73OtdfKAWte2JFxsw1PVT Xeh+ec7FJqNCKb2TwTSgnnWp6BxapbAlkK3kSwhsbgZvZLGtf3IC+xPHWNCs4dZs uCs9oDPC/oAiYBnN3gYZxBFuhe1fsFEuS7aFIzrvKD/+tnXmd0IQ5Yu3k06VDXIM jf/034Wep9AK44fyPy0sLKET1J6/UMvjxvUpEyxj9elbvs+GqzD9qR/GF6Ob8q6d 5f7y4ajMBCgyoC/wpIXDIJi7yqH1MUZq8bdC+7BKyc8Fz7kzVSpU2SL0BSRMU7Jn Mzyx25WbWy1mXkfdgOjXtxx6MH5gV6jIIvqobyXXrK/e0z3kU6OeFprbubsOAvmC fcgRkOrfr1O7/G5Gm7mhU5kLSZF6kvf6MoDPGCd/TbP4OgfYcPiTj5O020qDbRxZ Hfuy/5Xk1oxR2aui1q9ycCWrpSA4L+B4fSpDXUznZw755BhhPnVeoYlXUfcb2sI+ YPNs6cLeX95I27AoMpK0wjMptmswaKcDmwv50mjK0kXgUcnVGs6z7YxSIJ2eAxPV OpYLwVTfJiqoeJMscHvqoipwjlHqq4xS780SbzgZTDFOk2Ik7l0B6mNoL9CgaaXa LVCBEywdWo+9os4b3JRrjDSqqdOMhBVaO0GvtiZZqfF7mOTmJHF/yFAODBw/CLXi jAmBC/nM3M32CJphQQ1J =z7cJ -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 9/9] usb: dwc3: core: don't break during suspend/resume while we're dual-role
On 02/09/15 20:22, Sergei Shtylyov wrote: > Hello. > > On 09/02/2015 05:24 PM, Roger Quadros wrote: > >> We can't rely just on dr_mode to decide if we're in host or gadget >> mode when we're configured as otg/dual-role. So while dr_mode is >> OTG, we find out from the otg state machine if we're in host >> or gadget mode and take the necessary actions during suspend/resume. >> >> Also make sure that we disable OTG irq and events during system suspend >> so that we don't lockup the system during system suspend/resume. >> >> Signed-off-by: Roger Quadros>> --- >> drivers/usb/dwc3/core.c | 27 +-- >> 1 file changed, 9 insertions(+), 18 deletions(-) >> >> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c >> index 654aebf..25891e3 100644 >> --- a/drivers/usb/dwc3/core.c >> +++ b/drivers/usb/dwc3/core.c >> @@ -1455,18 +1455,15 @@ static int dwc3_suspend(struct device *dev) >> dwc->octl = dwc3_readl(dwc->regs, DWC3_OCTL); >> dwc->oevt = dwc3_readl(dwc->regs, DWC3_OEVT); >> dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN); >> +dwc3_writel(dwc->regs, DWC3_OEVTEN, 0); >> +disable_irq(dwc->otg_irq); >> } >> >> -switch (dwc->dr_mode) { >> -case USB_DR_MODE_PERIPHERAL: >> -case USB_DR_MODE_OTG: >> +if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL || >> +((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == >> PROTO_GADGET))) > >Hm, you're not very consistent about your parens. :-) You're right. Should be if ((dwc->dr_mode == USB_DR_MODE_PERIPHERAL) || ((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == PROTO_GADGET))) > > [...] >> @@ -1506,18 +1503,12 @@ static int dwc3_resume(struct device *dev) >> dwc3_writel(dwc->regs, DWC3_OCTL, dwc->octl); >> dwc3_writel(dwc->regs, DWC3_OEVT, dwc->oevt); >> dwc3_writel(dwc->regs, DWC3_OEVTEN, dwc->oevten); >> +enable_irq(dwc->otg_irq); >> } >> >> -switch (dwc->dr_mode) { >> -case USB_DR_MODE_PERIPHERAL: >> -case USB_DR_MODE_OTG: >> +if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL || >> +((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == >> PROTO_GADGET))) > >Same here... -- cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/9] usb: dwc3: core: make dual-role work with OTG irq
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/15 17:43, Felipe Balbi wrote: > Hi, > > On Wed, Sep 02, 2015 at 05:24:20PM +0300, Roger Quadros wrote: >> If the ID pin event is not available over extcon >> then we rely on the OTG controller to provide us ID and VBUS >> information. >> >> We still don't support any OTG features but just >> dual-role operation. >> >> Signed-off-by: Roger Quadros>> --- >> drivers/usb/dwc3/core.c | 217 >> >> drivers/usb/dwc3/core.h | 3 + >> 2 files changed, 205 insertions(+), 15 deletions(-) >> >> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c >> index 38b31df..632ee53 100644 >> --- a/drivers/usb/dwc3/core.c >> +++ b/drivers/usb/dwc3/core.c >> @@ -704,6 +704,63 @@ static int dwc3_core_get_phy(struct dwc3 *dwc) >> return 0; >> } >> >> +/* Get OTG events and sync it to OTG fsm */ >> +static void dwc3_otg_fsm_sync(struct dwc3 *dwc) >> +{ >> +u32 reg; >> +int id, vbus; >> + >> +reg = dwc3_readl(dwc->regs, DWC3_OSTS); >> +dev_dbg(dwc->dev, "otgstatus 0x%x\n", reg); >> + >> +id = !!(reg & DWC3_OSTS_CONIDSTS); >> +vbus = !!(reg & DWC3_OSTS_BSESVLD); >> + >> +if (id != dwc->fsm->id || vbus != dwc->fsm->b_sess_vld) { >> +dev_dbg(dwc->dev, "id %d vbus %d\n", id, vbus); >> +dwc->fsm->id = id; >> +dwc->fsm->b_sess_vld = vbus; >> +usb_otg_sync_inputs(dwc->fsm); >> +} > > this guy shouldn't try to filter events here. That's what the FSM should > be doing. OK. I'll remove the if condition. > >> +} >> + >> +static irqreturn_t dwc3_otg_thread_irq(int irq, void *_dwc) >> +{ >> +struct dwc3 *dwc = _dwc; >> +unsigned long flags; >> +irqreturn_t ret = IRQ_NONE; > > this IRQ will be disabled pretty quickly. You *always* return IRQ_NONE > >> +spin_lock_irqsave(>lock, flags); > > if you cache current OSTS in dwc3, you can use that instead and change > this to a spin_lock() instead of disabling IRQs here. This device's IRQs > are already masked anyway. OK. > >> +dwc3_otg_fsm_sync(dwc); >> +/* unmask interrupts */ >> +dwc3_writel(dwc->regs, DWC3_OEVTEN, dwc->oevten); >> +spin_unlock_irqrestore(>lock, flags); >> + >> +return ret; >> +} >> + >> +static irqreturn_t dwc3_otg_irq(int irq, void *_dwc) >> +{ >> +struct dwc3 *dwc = _dwc; >> +irqreturn_t ret = IRQ_NONE; >> +u32 reg; >> + >> +spin_lock(>lock); > > this seems unnecessary, we're already in hardirq with IRQs disabled. > What sort of race could we have ? (in fact, this also needs change in > dwc3/gadget.c). You're right. Will fix at both places. > >> + >> +reg = dwc3_readl(dwc->regs, DWC3_OEVT); >> +if (reg) { >> +dwc3_writel(dwc->regs, DWC3_OEVT, reg); >> +/* mask interrupts till processed */ >> +dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN); >> +dwc3_writel(dwc->regs, DWC3_OEVTEN, 0); >> +ret = IRQ_WAKE_THREAD; >> +} >> + >> +spin_unlock(>lock); >> + >> +return ret; >> +} >> + >> /* - Dual-Role management >> --- */ >> >> static void dwc3_drd_fsm_sync(struct dwc3 *dwc) >> @@ -728,15 +785,44 @@ static int dwc3_drd_start_host(struct otg_fsm *fsm, >> int on) >> { >> struct device *dev = usb_otg_fsm_to_dev(fsm); >> struct dwc3 *dwc = dev_get_drvdata(dev); >> +u32 reg; >> >> dev_dbg(dwc->dev, "%s: %d\n", __func__, on); >> +if (dwc->edev) { >> +if (on) { >> +dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST); >> +/* start the HCD */ >> +usb_otg_start_host(fsm, true); >> +} else { >> +/* stop the HCD */ >> +usb_otg_start_host(fsm, false); >> +} > > if (on) > dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST); > usb_otg_start_host(fsm, on); > OK. >> + >> +return 0; >> +} >> + >> +/* switch OTG core */ >> if (on) { >> -dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST); >> +/* OCTL.PeriMode = 0 */ >> +reg = dwc3_readl(dwc->regs, DWC3_OCTL); >> +reg &= ~DWC3_OCTL_PERIMODE; >> +dwc3_writel(dwc->regs, DWC3_OCTL, reg); >> +/* unconditionally turn on VBUS */ >> +reg |= DWC3_OCTL_PRTPWRCTL; >> +dwc3_writel(dwc->regs, DWC3_OCTL, reg); >> /* start the HCD */ >> usb_otg_start_host(fsm, true); >> } else { >> /* stop the HCD */ >> usb_otg_start_host(fsm, false); >> +/* turn off VBUS */ >> +reg = dwc3_readl(dwc->regs, DWC3_OCTL); >> +reg &= ~DWC3_OCTL_PRTPWRCTL; >> +dwc3_writel(dwc->regs, DWC3_OCTL, reg); >> +/* OCTL.PeriMode = 1 */ >> +reg =
Re: [PATCH v4 6/9] usb: dwc3: save/restore OTG registers during suspend/resume
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/15 17:44, Felipe Balbi wrote: > On Wed, Sep 02, 2015 at 05:24:21PM +0300, Roger Quadros wrote: >> Without this we loose OTG controller register context and malfunction >> after a system suspend-resume. >> >> Signed-off-by: Roger Quadros>> --- >> drivers/usb/dwc3/core.c | 17 + >> drivers/usb/dwc3/core.h | 6 +- >> 2 files changed, 22 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c >> index 632ee53..684010c 100644 >> --- a/drivers/usb/dwc3/core.c >> +++ b/drivers/usb/dwc3/core.c >> @@ -56,6 +56,7 @@ void dwc3_set_mode(struct dwc3 *dwc, u32 mode) >> reg = dwc3_readl(dwc->regs, DWC3_GCTL); >> reg &= ~(DWC3_GCTL_PRTCAPDIR(DWC3_GCTL_PRTCAP_OTG)); >> reg |= DWC3_GCTL_PRTCAPDIR(mode); >> +dwc->current_mode = mode; >> dwc3_writel(dwc->regs, DWC3_GCTL, reg); >> } >> >> @@ -1443,6 +1444,14 @@ static int dwc3_suspend(struct device *dev) >> >> spin_lock_irqsave(>lock, flags); >> >> +/* Save OTG state only if we're really using it */ >> +if (dwc->current_mode == DWC3_GCTL_PRTCAP_OTG) { >> +dwc->ocfg = dwc3_readl(dwc->regs, DWC3_OCFG); >> +dwc->octl = dwc3_readl(dwc->regs, DWC3_OCTL); >> +dwc->oevt = dwc3_readl(dwc->regs, DWC3_OEVT); > > oevt is what you use to clear pending IRQs, which means that ... > >> +dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN); >> +} >> + >> switch (dwc->dr_mode) { >> case USB_DR_MODE_PERIPHERAL: >> case USB_DR_MODE_OTG: >> @@ -1486,6 +1495,14 @@ static int dwc3_resume(struct device *dev) >> dwc3_event_buffers_setup(dwc); >> dwc3_writel(dwc->regs, DWC3_GCTL, dwc->gctl); >> >> +/* Restore OTG state only if we're really using it */ >> +if (dwc->current_mode == DWC3_GCTL_PRTCAP_OTG) { >> +dwc3_writel(dwc->regs, DWC3_OCFG, dwc->ocfg); >> +dwc3_writel(dwc->regs, DWC3_OCTL, dwc->octl); >> +dwc3_writel(dwc->regs, DWC3_OEVT, dwc->oevt); > > ... you could be clearing pending IRQs right here. Good catch. So we can't really restore this register. I'll remove this line. > >> +dwc3_writel(dwc->regs, DWC3_OEVTEN, dwc->oevten); >> +} >> + >> switch (dwc->dr_mode) { >> case USB_DR_MODE_PERIPHERAL: >> case USB_DR_MODE_OTG: >> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h >> index 129ef37..1115ce0 100644 >> --- a/drivers/usb/dwc3/core.h >> +++ b/drivers/usb/dwc3/core.h >> @@ -737,6 +737,7 @@ struct dwc3_scratchpad_array { >> * @regs: base address for our registers >> * @regs_size: address space size >> * @oevten: otg interrupt enable mask copy >> + * @current_mode: current mode of operation written to PRTCAPDIR >> * @nr_scratch: number of scratch buffers >> * @num_event_buffers: calculated number of event buffers >> * @u1u2: only used on revisions <1.83a for workaround >> @@ -858,9 +859,12 @@ struct dwc3 { >> /* used for suspend/resume */ >> u32 dcfg; >> u32 gctl; >> - >> +u32 ocfg; >> +u32 octl; >> +u32 oevt; >> u32 oevten; >> >> +u32 current_mode; >> u32 nr_scratch; >> u32 num_event_buffers; >> u32 u1u2; >> -- >> 2.1.4 >> > - -- cheers, - -roger -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV6FEGAAoJENJaa9O+djCTE7gP/0rlQJPL1R11k8hJCM842zjT SSxfdNQ9kkG008D88As8nLodL79agvD/XBot7iIrTGVFMG/tzzkwQb71gZoCOogb K0eMMnLNyzLRapNpOe1OJqI1NjO8Yx1o7heoaGkGYERR7m6dwz1LmSPYEtaaveVq 5gb5NbUKfSq0Cs6wM+3+U8CQzAPLf7eRSZwiORkzyn7cWiZDsYHr9Bn35NA24r5v 0YMQvmTp7K/7pFENiFHmOWbKPoY6G8ebkInBSMXQfHcLPtL86l9e+VrlJrIZzBqQ SJyoQw8JFU9c2ojtKeG9AYn8fSbCQpbsuIFAZtCVy2rK4xMiITmaSsjHF5+KpBt2 cE7eahicYAP3edLqT0R0hYfiI+JrVuOdkiW+W8UWPHrGt/nELQjQxZtIkTOI1b9B FIxnZbIwp0veEE+vqXiTQizUPdZag0qPG1PZ5Bpu0867vfX6khY2MCNeYTDatzHT dz9RwWIDH3/K5K7TOug/VZEiqvLY3BYMrMK+W3FreGfagwvYvlLyojsHifrA1x9z 1+zAjkml1kIIP5Jlf3VOYdLsN8mgeMyCNfi5USvVFnzPITAjtwm9+ai7xxxCjSxA QTvmhQRjAxIPWWZgVuc/Z5PdqgHKFKpCLxG8IE9bqGBQnNSKueZHEhfUCxfPNKV6 ZkkhIq/s6hm6S/YM4WcS =hUag -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 9/9] usb: dwc3: core: don't break during suspend/resume while we're dual-role
On 03/09/15 17:05, Sergei Shtylyov wrote: > Hello. > > On 09/03/2015 05:01 PM, Roger Quadros wrote: > We can't rely just on dr_mode to decide if we're in host or gadget mode when we're configured as otg/dual-role. So while dr_mode is OTG, we find out from the otg state machine if we're in host or gadget mode and take the necessary actions during suspend/resume. Also make sure that we disable OTG irq and events during system suspend so that we don't lockup the system during system suspend/resume. Signed-off-by: Roger Quadros--- drivers/usb/dwc3/core.c | 27 +-- 1 file changed, 9 insertions(+), 18 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 654aebf..25891e3 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -1455,18 +1455,15 @@ static int dwc3_suspend(struct device *dev) dwc->octl = dwc3_readl(dwc->regs, DWC3_OCTL); dwc->oevt = dwc3_readl(dwc->regs, DWC3_OEVT); dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN); +dwc3_writel(dwc->regs, DWC3_OEVTEN, 0); +disable_irq(dwc->otg_irq); } -switch (dwc->dr_mode) { -case USB_DR_MODE_PERIPHERAL: -case USB_DR_MODE_OTG: +if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL || +((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == PROTO_GADGET))) >>> >>> Hm, you're not very consistent about your parens. :-) >> >> You're right. Should be >> >> if ((dwc->dr_mode == USB_DR_MODE_PERIPHERAL) || >> ((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == >> PROTO_GADGET))) > >Parens around == are useless, I'd prefer if you deleted them. But if you'd > like to keep them, let it be so. :-) OK, how about this then? if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL || (dwc->dr_mode == USB_DR_MODE_OTG && dwc->fsm->protocol == PROTO_GADGET)) cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] regulator: Fix pbias regulator enable
* Kishon Vijay Abraham I[150903 02:25]: > On Thursday 03 September 2015 01:09 PM, Ulf Hansson wrote: > > > > Finally, perhaps it's better if we queue this through my mmc tree > > since we would then be able to avoid the regression - if I put > > $subject patchset before [1], right? Then I need an ack from Mark for > > the regulator patch. > > Please tell me if you guys prefer another way. That works for me too. Or Mark can set up an immutable signed branch that you can merge in, up to you guys. It's still going to break git bisect for booting but removes the regression when mergeing to mainline. I'd squash all the one liner dts changes into a single patch though when applying to cut down on the commit noise. 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 v2] security: device_cgroup: fix RCU lockdep splat
On Wed, Sep 02, 2015 at 05:14:33PM -0700, Paul E. McKenney wrote: > On Wed, Sep 02, 2015 at 12:24:50PM -0400, Tejun Heo wrote: > > cc'ing Paul. > > > > On Wed, Sep 02, 2015 at 08:12:28AM -0500, Felipe Balbi wrote: > > > while booting AM437x device, the following splat > > > triggered: > > > > > > [ 12.005238] === > > > [ 12.009749] [ INFO: suspicious RCU usage. ] > > > [ 12.014116] 4.2.0-next-20150831 #1154 Not tainted > > > [ 12.019050] --- > > > [ 12.023408] security/device_cgroup.c:405 device_cgroup:verify_new_ex > > > called without proper synchronization! > > ... > > > [ 12.128326] [] (verify_new_ex) from [] > > > (devcgroup_access_write+0x374/0x658) > > > [ 12.137426] [] (devcgroup_access_write) from [] > > > (cgroup_file_write+0x28/0x1bc) > > > [ 12.146796] [] (cgroup_file_write) from [] > > > (kernfs_fop_write+0xc0/0x1b8) > > > [ 12.155620] [] (kernfs_fop_write) from [] > > > (__vfs_write+0x1c/0xd8) > > > [ 12.163783] [] (__vfs_write) from [] > > > (vfs_write+0x90/0x16c) > > > [ 12.171426] [] (vfs_write) from [] > > > (SyS_write+0x44/0x9c) > > > [ 12.178806] [] (SyS_write) from [] > > > (ret_fast_syscall+0x0/0x1c) > > > > This shouldn't be happening because devcgroup_access_write() always > > grabs devcgroup_mutex. Looking at the log, the culprit seems to be > > f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to > > RCU_LOCKDEP_WARN()"). It missed the bang for the second test while > > inverting it, so adding rcu_read_lock() isn't the right fix here. > > > > Paul, can you please fix it? > > Gah! Please see below. > > Thanx, Paul > > > > security/device_cgroup: Fix RCU_LOCKDEP_WARN() condition > > f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()") > introduced a bug by incorrectly inverting the condition when moving from > rcu_lockdep_assert() to RCU_LOCKDEP_WARN(). This commit therefore fixes > the inversion. > > Reported-by: Felipe Balbi> Reported-by: Tejun Heo > Signed-off-by: Paul E. McKenney > Cc: Serge Hallyn Oh, makes sense :) (didn't see the original patch when it came by, sorry) Acked-by: Serge Hallyn > diff --git a/security/device_cgroup.c b/security/device_cgroup.c > index 73455089feef..03c1652c9a1f 100644 > --- a/security/device_cgroup.c > +++ b/security/device_cgroup.c > @@ -401,7 +401,7 @@ static bool verify_new_ex(struct dev_cgroup *dev_cgroup, > bool match = false; > > RCU_LOCKDEP_WARN(!rcu_read_lock_held() && > - lockdep_is_held(_mutex), > + !lockdep_is_held(_mutex), >"device_cgroup:verify_new_ex called without proper > synchronization"); > > if (dev_cgroup->behavior == DEVCG_DEFAULT_ALLOW) { -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] omap: Fix broken address translation for pbias
* Kishon Vijay Abraham I[150903 04:31]: > pbias device stopped having memory resource after > "ARM: dts: : add minimal l4 bus layout with control module > support" got merged. This results in platform_get_resource returning > -EINVAL in pbias driver. This is because address translation fails > while trying to convert the address to resource which happens > during the device creation process during boot up. > > Even though after [1], reg property in pbias dt node is un-used, > it might be an issue if we plan to use it at a later point of time. > > Patch series is created on top of [1]. > > [1] -> https://lkml.org/lkml/2015/9/3/51 > > Verified the address in omap4 panda, omap5 uevm and dra72 boards. Your other series is obviously needed for v4.3.. But seems these are also needed for stable? If so, which versions, v4.2+? Can you please just do a single patch with multiple Fixes tags as they fix regression for multiple commits? Doing tons of one liner patches for the same thing just creates commit log noise.. Remember to not Cc stable when posting, I'll add that tag when committing if needed. 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 v4 9/9] usb: dwc3: core: don't break during suspend/resume while we're dual-role
Hello. On 09/03/2015 05:01 PM, Roger Quadros wrote: We can't rely just on dr_mode to decide if we're in host or gadget mode when we're configured as otg/dual-role. So while dr_mode is OTG, we find out from the otg state machine if we're in host or gadget mode and take the necessary actions during suspend/resume. Also make sure that we disable OTG irq and events during system suspend so that we don't lockup the system during system suspend/resume. Signed-off-by: Roger Quadros--- drivers/usb/dwc3/core.c | 27 +-- 1 file changed, 9 insertions(+), 18 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 654aebf..25891e3 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -1455,18 +1455,15 @@ static int dwc3_suspend(struct device *dev) dwc->octl = dwc3_readl(dwc->regs, DWC3_OCTL); dwc->oevt = dwc3_readl(dwc->regs, DWC3_OEVT); dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN); +dwc3_writel(dwc->regs, DWC3_OEVTEN, 0); +disable_irq(dwc->otg_irq); } -switch (dwc->dr_mode) { -case USB_DR_MODE_PERIPHERAL: -case USB_DR_MODE_OTG: +if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL || +((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == PROTO_GADGET))) Hm, you're not very consistent about your parens. :-) You're right. Should be if ((dwc->dr_mode == USB_DR_MODE_PERIPHERAL) || ((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == PROTO_GADGET))) Parens around == are useless, I'd prefer if you deleted them. But if you'd like to keep them, let it be so. :-) -- cheers, -roger MBR, Sergei -- 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: [net-next PATCH v2] drivers: net: cpsw: Add support to make gpio drive which slave connected to phy
* Mugunthan V N[150902 23:05]: > In DRA72x EVM, by default slave 1 is connected to the onboard > phy, but slave 2 pins are also muxed with video input module > which is controlled by pcf857x gpio and currently to select slave > 0 to connect to phy gpio hogging is used, but with > omap2plus_defconfig the pcf857x gpio is built as module. So when > using NFS on DRA72x EVM, board doesn't boot as gpio hogging do > not set proper gpio state to connect slave 0 to phy as it is > built as module and you do not see any errors for not setting > gpio and just mentions dhcp reply not got. > > To solve this issue, introducing "mode-gpio" in DT when gpio > based muxing is required. This will throw a warning when gpio > get fails and returns probe defer. When gpio-pcf857x module is > installed, cpsw probes again and ethernet becomes functional. > Verified this on DRA72x with pcf as module and ramdisk. Hmm you might be able to make it even a little bit more generic. The gpios can be an array.. So typically they're named "-gpios": [linux] $ git grep "\-gpio " arch/arm/boot/dts/*.dts* | wc -l 219 [linux] $ git grep "\-gpios " arch/arm/boot/dts/*.dts* | wc -l 704 So I'd use mode-gpios even though there's just one gpio in this case. Up to you though, and should be retested after the change naturally. At some point gpio code was not parsing "gpio" or "gpios" properly.. But that's probably been fixed a long time ago. 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: [RFC PATCH 1/4] ARM: OMAP2: DRA7: Modify optimize string comparisons in soc_is calls
* Felipe Balbi[150902 05:34]: > On Wed, Sep 02, 2015 at 03:50:10PM +0530, Keerthy wrote: > > Currently everytime soc_is calls are made, firstly device tree nodes > > are parsed and then string comparisons are made to determine the > > soc version. Optimizing it to be done one time and store the result. > > but is that really a problem ? Are soc_is* calls made in any critical > path ? Please provide some benchmarking data. Regarding the SoC detection, there are multiple issues to consider here: 1. We want to unify the SoC detection so it behaves the same way for all SoCs 2. We don't want the dts files to explode with boards having multiple SoC revisions. So SoC detection and features detection for SGX and DSP etc should be done after setting the major SoC class based on compatible value 3. We don't want to do pointless string comparison over and over 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] ARM: multi_v7_defconfig: Enable PBIAS regulator
* Kishon Vijay Abraham I[150903 02:58]: > PBIAS regulator is required for MMC module in OMAP2, OMAP3, OMAP4, > OMAP5 and DRA7 SoCs. Enable it here. > > Signed-off-by: Kishon Vijay Abraham I For the multi_v7_defconfig changes you need to resend this to a...@kernel.org. This is to avoid conflicts with other patches. Regards, Tony > arch/arm/configs/multi_v7_defconfig |1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/multi_v7_defconfig > b/arch/arm/configs/multi_v7_defconfig > index 5fd8df6..f497c96 100644 > --- a/arch/arm/configs/multi_v7_defconfig > +++ b/arch/arm/configs/multi_v7_defconfig > @@ -403,6 +403,7 @@ CONFIG_REGULATOR_MAX8973=y > CONFIG_REGULATOR_MAX77686=y > CONFIG_REGULATOR_MAX77693=m > CONFIG_REGULATOR_PALMAS=y > +CONFIG_REGULATOR_PBIAS=y > CONFIG_REGULATOR_S2MPS11=y > CONFIG_REGULATOR_S5M8767=y > CONFIG_REGULATOR_TPS51632=y > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 9/9] usb: dwc3: core: don't break during suspend/resume while we're dual-role
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/15 17:48, Felipe Balbi wrote: > On Wed, Sep 02, 2015 at 05:24:24PM +0300, Roger Quadros wrote: >> We can't rely just on dr_mode to decide if we're in host or gadget >> mode when we're configured as otg/dual-role. So while dr_mode is >> OTG, we find out from the otg state machine if we're in host >> or gadget mode and take the necessary actions during suspend/resume. >> >> Also make sure that we disable OTG irq and events during system suspend >> so that we don't lockup the system during system suspend/resume. >> >> Signed-off-by: Roger Quadros>> --- >> drivers/usb/dwc3/core.c | 27 +-- >> 1 file changed, 9 insertions(+), 18 deletions(-) >> >> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c >> index 654aebf..25891e3 100644 >> --- a/drivers/usb/dwc3/core.c >> +++ b/drivers/usb/dwc3/core.c >> @@ -1455,18 +1455,15 @@ static int dwc3_suspend(struct device *dev) >> dwc->octl = dwc3_readl(dwc->regs, DWC3_OCTL); >> dwc->oevt = dwc3_readl(dwc->regs, DWC3_OEVT); >> dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN); >> +dwc3_writel(dwc->regs, DWC3_OEVTEN, 0); >> +disable_irq(dwc->otg_irq); > > you don't need disable_irq() here. In fact, it causes problems since > you're calling it with IRQs disabled. OK. will remove it. > >> } >> >> -switch (dwc->dr_mode) { >> -case USB_DR_MODE_PERIPHERAL: >> -case USB_DR_MODE_OTG: >> +if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL || >> +((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == >> PROTO_GADGET))) >> dwc3_gadget_suspend(dwc); >> -/* FALLTHROUGH */ >> -case USB_DR_MODE_HOST: >> -default: >> -dwc3_event_buffers_cleanup(dwc); >> -break; >> -} >> + >> +dwc3_event_buffers_cleanup(dwc); >> >> dwc->gctl = dwc3_readl(dwc->regs, DWC3_GCTL); >> spin_unlock_irqrestore(>lock, flags); >> @@ -1506,18 +1503,12 @@ static int dwc3_resume(struct device *dev) >> dwc3_writel(dwc->regs, DWC3_OCTL, dwc->octl); >> dwc3_writel(dwc->regs, DWC3_OEVT, dwc->oevt); >> dwc3_writel(dwc->regs, DWC3_OEVTEN, dwc->oevten); >> +enable_irq(dwc->otg_irq); >> } >> >> -switch (dwc->dr_mode) { >> -case USB_DR_MODE_PERIPHERAL: >> -case USB_DR_MODE_OTG: >> +if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL || >> +((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == >> PROTO_GADGET))) >> dwc3_gadget_resume(dwc); >> -/* FALLTHROUGH */ >> -case USB_DR_MODE_HOST: >> -default: >> -/* do nothing */ >> -break; >> -} >> >> spin_unlock_irqrestore(>lock, flags); >> >> -- >> 2.1.4 >> > - -- cheers, - -roger -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV6FLtAAoJENJaa9O+djCTxnMQANGOTEBjO8E9v32qfrgwL6X+ VyTeGBHhfwv7/u7xOM0im6tfXXaLtjj16mEY8fePC+oXO2Vv3RDxi0HTiF6sePnT odt8nTOYGq7arPAKrtL8BK/8xyJRDjijXWGdQDAgPT1D5V2y8Ib4AbkM2j5IkL+/ 75EGybhxIPNGNEV2eS/OBn2BPWSzn/r6rFMJiuYPY2yoPQqwG1ovdt+K+tvMybvZ sYdQxu4UPN1z1pKplmCQxmPut9SyCqIAeHXdWGT6kJsleBsv2WNM1ZdM/y4zZmMw gpyNOs+HYqdd/llfEYFrSRnSM2io2GyKZ73xM+DVfY8ot7Vf/h4x41Dz4V19jqtC 3IoyPzNb+inbsRKs0GhTw3yD9N8b7xRbVF+qZPIvDvn7QGLF2pY8cDiqZE1LiOs2 VpKBRoC0wdmdQ/bjRMt516jFmJiQ2RbR2SenGffIr+PrCb1EQ7Fmwtoya5FPgIz/ nMdL7g1MGHUzWvzXTYO+RH4bHV9cDL66qekOL7PR1yEyAAo09vLc+ds/4z85MGQ6 2JYKYb4Mdtv2EAOzIqNR3+FzcCawpZbhm8bBFz14Kj12pgjwl5A3o+fYaZ4Q07OK ZfFRAUG4RKFNVcjb7hhiBPdN+mb34/50YreFcNj/MOYwklXwUAmgiTFH7cjO9SA7 XZpbfSRwT4Ec4WWqTeeR =unNn -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 9/9] usb: dwc3: core: don't break during suspend/resume while we're dual-role
On 09/03/2015 05:10 PM, Roger Quadros wrote: We can't rely just on dr_mode to decide if we're in host or gadget mode when we're configured as otg/dual-role. So while dr_mode is OTG, we find out from the otg state machine if we're in host or gadget mode and take the necessary actions during suspend/resume. Also make sure that we disable OTG irq and events during system suspend so that we don't lockup the system during system suspend/resume. Signed-off-by: Roger Quadros--- drivers/usb/dwc3/core.c | 27 +-- 1 file changed, 9 insertions(+), 18 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 654aebf..25891e3 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -1455,18 +1455,15 @@ static int dwc3_suspend(struct device *dev) dwc->octl = dwc3_readl(dwc->regs, DWC3_OCTL); dwc->oevt = dwc3_readl(dwc->regs, DWC3_OEVT); dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN); +dwc3_writel(dwc->regs, DWC3_OEVTEN, 0); +disable_irq(dwc->otg_irq); } -switch (dwc->dr_mode) { -case USB_DR_MODE_PERIPHERAL: -case USB_DR_MODE_OTG: +if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL || +((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == PROTO_GADGET))) Hm, you're not very consistent about your parens. :-) You're right. Should be if ((dwc->dr_mode == USB_DR_MODE_PERIPHERAL) || ((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == PROTO_GADGET))) Parens around == are useless, I'd prefer if you deleted them. But if you'd like to keep them, let it be so. :-) OK, how about this then? if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL || (dwc->dr_mode == USB_DR_MODE_OTG && dwc->fsm->protocol == PROTO_GADGET)) Strictly speaking, parens around && are also not needed but gcc may probably issue a warning without them. Not sure, your call. cheers, -roger MBR, Sergei -- 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] pinctrl: core: Warn about NULL gpio_chip in pinctrl_ready_for_gpio_range()
If the gpio driver is confused about the numbers for gpio-ranges, pinctrl_ready_for_gpio_range() may get called with invalid GPIO causing a NULL pointer exception. Let's instead provide a warning that allows fixing the problem and return with error. Signed-off-by: Tony Lindgren--- drivers/pinctrl/core.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/pinctrl/core.c +++ b/drivers/pinctrl/core.c @@ -349,6 +349,9 @@ static bool pinctrl_ready_for_gpio_range(unsigned gpio) struct pinctrl_gpio_range *range = NULL; struct gpio_chip *chip = gpio_to_chip(gpio); + if (WARN(!chip, "no gpio_chip for gpio%i?", gpio)) + return false; + mutex_lock(_list_mutex); /* Loop over the pin controllers */ -- 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
[PATCH] gpio: omap: Fix GPIO numbering for deferred probe
If gpio-omap probe fails with -EPROBE_DEFER, the GPIO numbering keeps increasing. Only increase the gpio count if gpiochip_add() was successful as otherwise the numbers will increase for each probe attempt. Cc: Grygorii StrashkoCc: Javier Martinez Canillas Cc: Kevin Hilman Cc: Santosh Shilimkar Signed-off-by: Tony Lindgren --- drivers/gpio/gpio-omap.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -1095,7 +1095,6 @@ static int omap_gpio_chip_init(struct gpio_bank *bank, struct irq_chip *irqc) } else { bank->chip.label = "gpio"; bank->chip.base = gpio; - gpio += bank->width; } bank->chip.ngpio = bank->width; @@ -1105,6 +1104,9 @@ static int omap_gpio_chip_init(struct gpio_bank *bank, struct irq_chip *irqc) return ret; } + if (!bank->is_mpuio) + gpio += bank->width; + #ifdef CONFIG_ARCH_OMAP1 /* * REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop -- 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
[PATCH] ARM: dts: am57xx-beagle-x15: Add wakeup irq for mcp79410
With the support in the generic PM framework for wakeirq and capability added to the rtc-ds1307 driver to support this, we can now define the optional wakeup irq to allow the RTC to wakeup the system from low power modes as part of suspend. Signed-off-by: Nishanth Menon--- This patch depends on upcoming merge for RTC https://git.kernel.org/cgit/linux/kernel/git/abelloni/linux.git/log/?h=rtc-next=50 merge to master of: 9901c41bd019 rtc: ds1307: Support optional wakeup interrupt source 496a7ede6cac rtc: ds1307: Sort the headers e28475b15b65 rtc: ds1307: Switch to managed irq allocation 27a1dce6528a rtc: ds1307: Convert to threaded IRQ Tested with the above commits from linux-next: http://pastebin.ubuntu.com/12265857/ Could probably go in round 2 of merges for 4.3? arch/arm/boot/dts/am57xx-beagle-x15.dts |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts b/arch/arm/boot/dts/am57xx-beagle-x15.dts index ede7fb73c717..8464f3cea280 100644 --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts @@ -526,7 +526,8 @@ mcp_rtc: rtc@6f { compatible = "microchip,mcp7941x"; reg = <0x6f>; - interrupts = ; /* IRQ_SYS_1N */ + interrupts-extended = <_mpu GIC_SPI 2 IRQ_TYPE_EDGE_RISING>, + <_pmx_core 0x424>; pinctrl-names = "default"; pinctrl-0 = <_pins_default>; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: am57xx-beagle-x15: Update Phy supplies
Originally, all the SoC PHY rails were supplied by LDO3. However, as a result of characterization, it was determined that this posed a risk in extreme load conditions. Hence the PHY rails are split between two different LDOs. Update the related node as a result LDO3/VDDA_1V8_PHYA supplies vdda_usb1, vdda_usb2, vdda_sata, vdda_usb3 LDO4/VDDA_1V8_PHYB supplies vdda_pcie1, vdda_pcie0, vdda_hdmi, vdda_pcie NOTE: We break compatibility with pre-production boards with this change since, the PMIC LDO4 is disabled at OTP level. The new configuration is the plan of record and all pre-production boards are supposed to be replaced with the latest boards matching the mentioned configuration. Signed-off-by: Nishanth Menon--- arch/arm/boot/dts/am57xx-beagle-x15.dts | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts b/arch/arm/boot/dts/am57xx-beagle-x15.dts index 3a05b94f59ed..ede7fb73c717 100644 --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts @@ -432,7 +432,7 @@ }; ldo3_reg: ldo3 { - /* VDDA_1V8_PHY */ + /* VDDA_1V8_PHYA */ regulator-name = "ldo3"; regulator-min-microvolt = <180>; regulator-max-microvolt = <180>; @@ -440,6 +440,15 @@ regulator-boot-on; }; + ldo4_reg: ldo4 { + /* VDDA_1V8_PHYB */ + regulator-name = "ldo4"; + regulator-min-microvolt = <180>; + regulator-max-microvolt = <180>; + regulator-always-on; + regulator-boot-on; + }; + ldo9_reg: ldo9 { /* VDD_RTC */ regulator-name = "ldo9"; @@ -681,7 +690,7 @@ { status = "ok"; - vdda-supply = <_reg>; + vdda-supply = <_reg>; pinctrl-names = "default"; pinctrl-0 = <_pins>; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/9] usb: dwc3: core: Adapt to named interrupts
Hi, On Thu, Sep 03, 2015 at 03:46:43PM +0300, Roger Quadros wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 02/09/15 17:34, Felipe Balbi wrote: > > On Wed, Sep 02, 2015 at 05:24:19PM +0300, Roger Quadros wrote: > >> From: Felipe Balbi> >> > >> Add support to use interrupt names, > >> > >> Following are the interrupt names > >> > >> Peripheral Interrupt - peripheral > >> HOST Interrupt - host > >> OTG Interrupt - otg > >> > >> [Roger Q] > >> - If any of these are missing we use the > >> first available IRQ resource so that we don't > >> break with older DTBs. > > > > this is what original commit did: > > > > commit ecd5f71cfd663bcd4efd2f29824acd8b2ba9715d > > Author: Felipe Balbi > > Date: Fri Jan 3 13:49:38 2014 -0600 > > > > usb: dwc3: cleanup IRQ resources > > > > In order to make it easier for the driver to > > figure out which modes of operation it has, > > and because some dwc3 integrations have rather > > fuzzy IRQ routing, we now require three different > > IRQ numbers (peripheral, host, otg). > > > > In order to do that and maintain backwards compatibility, > > we still maintain support for the old IRQ resource name, > > but if you *really* want to have proper peripheral/host/otg > > support, you should make sure your resources are correct. > > > > Signed-off-by: Felipe Balbi > > This is better since we request the resource only if needed and bail out > if it is not present. > > > > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c > > index 60580a01cdd2..1f01031873b7 100644 > > --- a/drivers/usb/dwc3/core.c > > +++ b/drivers/usb/dwc3/core.c > > @@ -556,10 +556,22 @@ static int dwc3_core_get_phy(struct dwc3 *dwc) > > static int dwc3_core_init_mode(struct dwc3 *dwc) > > { > > struct device *dev = dwc->dev; > > + struct platform_device *pdev = to_platform_device(dev); > > int ret; > > > > switch (dwc->dr_mode) { > > case USB_DR_MODE_PERIPHERAL: > > + dwc->gadget_irq = platform_get_irq_byname(pdev, > > "dwc3_peripheral"); > > Shall we just name it just "peripheral"? sure, why not :-) > > + if (dwc->gadget_irq < 0) { > > + dwc->gadget_irq = platform_get_irq_byname(pdev, > > "dwc_usb3"); > > How will this work? Currently we don't have a name for the IRQ in the DT. we can just add interrupt-names, right ? Or, the fallback could be what is already done today: just fetch it by index. > > > + if (dwc->gadget_irq < 0) { > > + dev_err(dev, "missing IRQ\n"); > > + return dwc->gadget_irq; > > + } else { > > + dev_warn(dev, "dwc_usb3 resource is > > deprecated\n"); > > Do we want to warn about legacy nodes? Sure :-) Now, do you want me to update it, or will you do it ? BTW, if you decide to do it, we need to patch all users :-) > > @@ -576,6 +604,28 @@ static int dwc3_core_init_mode(struct dwc3 *dwc) > > } > > break; > > case USB_DR_MODE_OTG: > > + dwc->gadget_irq = platform_get_irq_byname(pdev, > > "dwc3_peripheral"); > > + if (dwc->gadget_irq < 0) { > > + dwc->gadget_irq = platform_get_irq_byname(pdev, > > "dwc_usb3"); > > + if (dwc->gadget_irq < 0) { > > + dev_err(dev, "missing IRQ\n"); > > + return dwc->gadget_irq; > > + } else { > > + dev_warn(dev, "dwc_usb3 resource is > > deprecated\n"); > > + } > > + > > + dwc->xhci_irq = dwc->gadget_irq; > > + dwc->otg_irq = dwc->gadget_irq; > > + } else { > > + dwc->xhci_irq = platform_get_irq_byname(pdev, > > "dwc3_host"); > > + if (dwc->xhci_irq < 0) { > > + dev_err(dev, "missing Host IRQ\n"); > > + return dwc->xhci_irq; > > + } > > + > > + dwc->otg_irq = platform_get_irq_byname(pdev, > > "dwc3_otg"); > > need to check if error? right > > + } > > Need to setup xhci_resource[1]? isn't it done above ? -- balbi signature.asc Description: Digital signature
Re: PowerVR SGX540 drivers for PandaBoard(OMAP4460) on vanilla kernel
* Sedat Marangoz[150902 01:24]: > Tried hard but nothing available my hands except my experiences. I > gave up trying custom kernel due to lots of error, and instead tried > Ubuntu precise 3.2.0-1412-omap4 kernel which is one of the working > kernel with SGX540 driver module. I built "omapdrm_pvr.ko" and load > this module without error. Beside kernel module, user space libraries > are needed for running with hardware acceleration. However these user > space libraries also depends on X11, and my file system does not > contain any library related X11. Even if kernel module loaded > successfully, it seems it is impossible to use PVR without X11 > libraries(mentioned here: > http://pandaboard.org/pbirclogs/index.php?date=2011-12-29 ) > > Dependency tree: > > libpvrPVR2D_DRIWSEGL.so.1.7.10.0 > -> [libpvr2d.so] > -> [libdl.so.2] > -> [libdrm.so.2] > -> [libX11.so.6] > -> [libxcb.so.1] > -> [libXau.so.6] > -> [libXdmcp.so.6] > -> [libc.so.6] > -> [ld-linux.so.3] > -> [libdl.so.2] > -> [libc.so.6] > -> [ld-linux.so.3] > -> [libXext.so.6] > -> [libX11.so.6] > -> [libc.so.6] > -> [ld-linux.so.3] > > -> [libXfixes.so.3] > -> [libX11.so.6] > -> [libc.so.6] > > So, it seems currently there is no way to install SGX540 driver to > Pandaboard ES (OMAP4460) which has custom kernel such as version > 3.10.80 and small filesystem(without X11) :( Sorry no idea why the libX11 dependency is there.. I was mostly thinking if there's something we should patch in the mainline kernel to make things easier. > In my opinion, another platform such as BeagleBone Black which has > SGX530 is more appropriate for my needs, I have already used modules > and libraries for hardware acceleration without x11. OK that sounds right to me. 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 v4 1/9] usb: dwc3: add dual-role support
Hi, On Thu, Sep 03, 2015 at 03:21:48PM +0300, Roger Quadros wrote: > >> + dwc->fsm->id = id; > >> + dwc->fsm->b_sess_vld = vbus; > >> + usb_otg_sync_inputs(dwc->fsm); > >> +} > >> + > >> +static int dwc3_drd_start_host(struct otg_fsm *fsm, int on) > >> +{ > >> + struct device *dev = usb_otg_fsm_to_dev(fsm); > >> + struct dwc3 *dwc = dev_get_drvdata(dev); > > > > how about adding a usb_otg_get_drvdata(fsm) ? > > You meant for otg core? That can be done. yeah. BTW, I think otg core needs quite a few changes to become actually useful. Currently it's just too much pointer ping-pong going back and forth between phy, otg core, udc and hcd. Also, I caught a ton of issues with it and suspend/resume. You might want to fix them before adding more users to it. It's also rather racy and that needs fixing too. On top of all that, I think there's too much being added to UDC just to get Dual-Role, let's see if we can improve that too. > >> @@ -843,6 +998,16 @@ static int dwc3_probe(struct platform_device *pdev) > >>hird_threshold = 12; > >> > >>if (node) { > >> + if (of_property_read_bool(node, "extcon")) > >> + dwc->edev = extcon_get_edev_by_phandle(dev, 0); > >> + else if (of_property_read_bool(dev->parent->of_node, "extcon")) > >> + dwc->edev = extcon_get_edev_by_phandle(dev->parent, 0); > > > > why do you need to check the parent ? Why isn't that done on the glue > > layer ? > > On DRA7-evm, the extcon device is defined in the glue layer node. But > we need the device both at the glue layer and at the core layer. why do you need extcon here ? Glue updates core via UTMI about the states, right ? So you should get proper VBUS and ID status via OTG IRQ. Is that not working ? > We do get the extcon device in dwc3-omap.c > > Any suggestion how to pass the extcon device from glue layer to core.c? > Or should I add the extcon property to dwc3 USB node as well in the DT? GPIO toggles dwc3-omap extcon event update status via UTMI STATUS register OTG IRQ on core Horray! :-) > >> + > >> + if (IS_ERR(dwc->edev)) { > >> + dev_vdbg(dev, "couldn't get extcon device\n"); > > > > dev_err() ?? > > Is it ok to print it even in EPROBE_DEFER case? hmm, probably pointless, indeed. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 5/9] usb: dwc3: core: make dual-role work with OTG irq
Hi, On Thu, Sep 03, 2015 at 04:52:02PM +0300, Roger Quadros wrote: > >>if (on) { > >> - dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST); > >> + /* OCTL.PeriMode = 0 */ > >> + reg = dwc3_readl(dwc->regs, DWC3_OCTL); > >> + reg &= ~DWC3_OCTL_PERIMODE; > >> + dwc3_writel(dwc->regs, DWC3_OCTL, reg); > >> + /* unconditionally turn on VBUS */ > >> + reg |= DWC3_OCTL_PRTPWRCTL; > >> + dwc3_writel(dwc->regs, DWC3_OCTL, reg); > >>/* start the HCD */ > >>usb_otg_start_host(fsm, true); > >>} else { > >>/* stop the HCD */ > >>usb_otg_start_host(fsm, false); > >> + /* turn off VBUS */ > >> + reg = dwc3_readl(dwc->regs, DWC3_OCTL); > >> + reg &= ~DWC3_OCTL_PRTPWRCTL; > >> + dwc3_writel(dwc->regs, DWC3_OCTL, reg); > >> + /* OCTL.PeriMode = 1 */ > >> + reg = dwc3_readl(dwc->regs, DWC3_OCTL); > >> + reg |= DWC3_OCTL_PERIMODE; > >> + dwc3_writel(dwc->regs, DWC3_OCTL, reg); > >>} > > > > it looks like you're not really following the fluxchart from SNPS > > documentation, see Figure 11-4 on section 11.1.4.5 > > Did you mean that I'm ignoring all OTG bits (HNP/SRP/ADP)? yes and no :-) There's a rather complex flux chart which details how we switch from host to peripheral and vice versa. We need to follow that to the smallest details since that's what IP provider considers to be correct. If we deviate from that we should have very strong reasons for doing so and we also want big, fat, long comments in source code detailing why and how we're deviating :-) -- balbi signature.asc Description: Digital signature
RE: [PATCH 2/3][v3] drivers: usb: dwc3: Add frame length adjustment quirk
> -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Thursday, September 03, 2015 9:25 PM > To: Badola Nikhil-B46172> Cc: linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; linux- > o...@vger.kernel.org; ba...@ti.com; gre...@linuxfoundation.org > Subject: Re: [PATCH 2/3][v3] drivers: usb: dwc3: Add frame length > adjustment quirk > > On Thu, Sep 03, 2015 at 11:34:04AM +0530, Nikhil Badola wrote: > > Add adjust_frame_length_quirk for writing to fladj register which > > adjusts (micro)frame length to value provided by > > "snps,quirk-frame-length-adjustment" property thus avoiding USB 2.0 > > devices to time-out over a longer run > > > > Signed-off-by: Nikhil Badola > > --- > > Changes for v3: > > - removed unnecessary if(fladj) condition > > - removed stray newline > > > > drivers/usb/dwc3/core.c | 34 > ++ > > drivers/usb/dwc3/core.h | 5 + > > drivers/usb/dwc3/platform_data.h | 2 ++ > > 3 files changed, 41 insertions(+) > > > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index > > 064123e..75a17bf 100644 > > --- a/drivers/usb/dwc3/core.c > > +++ b/drivers/usb/dwc3/core.c > > @@ -143,6 +143,32 @@ static int dwc3_soft_reset(struct dwc3 *dwc) > > return 0; > > } > > > > +/* > > + * dwc3_frame_length_adjustment - Adjusts frame length if required > > + * @dwc3: Pointer to our controller context structure > > + * @fladj: Value of GFLADJ_30MHZ to adjust frame length */ static > > +void dwc3_frame_length_adjustment(struct dwc3 *dwc, u32 fladj) { > > + if (dwc->revision < DWC3_REVISION_250A) > > + return; > > + > > + if (fladj == 0) > > + return; > > + > > + u32 reg; > > + u32 dft; > > are you seriously telling me that GCC didn't warn you about mixing > declaration and code ? That's really careless of me. Somehow this warning skipped my attention. Apologies for this silly thing. I will resend the patch. -- 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/3][v3] drivers: usb: dwc3: Add frame length adjustment quirk
On Thu, Sep 03, 2015 at 11:34:04AM +0530, Nikhil Badola wrote: > Add adjust_frame_length_quirk for writing to fladj register > which adjusts (micro)frame length to value provided by > "snps,quirk-frame-length-adjustment" property thus avoiding > USB 2.0 devices to time-out over a longer run > > Signed-off-by: Nikhil Badola> --- > Changes for v3: > - removed unnecessary if(fladj) condition > - removed stray newline > > drivers/usb/dwc3/core.c | 34 ++ > drivers/usb/dwc3/core.h | 5 + > drivers/usb/dwc3/platform_data.h | 2 ++ > 3 files changed, 41 insertions(+) > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c > index 064123e..75a17bf 100644 > --- a/drivers/usb/dwc3/core.c > +++ b/drivers/usb/dwc3/core.c > @@ -143,6 +143,32 @@ static int dwc3_soft_reset(struct dwc3 *dwc) > return 0; > } > > +/* > + * dwc3_frame_length_adjustment - Adjusts frame length if required > + * @dwc3: Pointer to our controller context structure > + * @fladj: Value of GFLADJ_30MHZ to adjust frame length > + */ > +static void dwc3_frame_length_adjustment(struct dwc3 *dwc, u32 fladj) > +{ > + if (dwc->revision < DWC3_REVISION_250A) > + return; > + > + if (fladj == 0) > + return; > + > + u32 reg; > + u32 dft; are you seriously telling me that GCC didn't warn you about mixing declaration and code ? -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH 1/4] ARM: OMAP2: DRA7: Modify optimize string comparisons in soc_is calls
* Keerthy[150902 03:23]: > Currently everytime soc_is calls are made, firstly device tree nodes > are parsed and then string comparisons are made to determine the > soc version. Optimizing it to be done one time and store the result. > Use the stored value in all the subsequent checks for soc_is calls. ... > --- a/arch/arm/mach-omap2/id.c > +++ b/arch/arm/mach-omap2/id.c > @@ -44,12 +44,29 @@ static char soc_name[OMAP_SOC_MAX_NAME_LENGTH]; > static char soc_rev[OMAP_SOC_MAX_NAME_LENGTH]; > u32 omap_features; > > +static int soc_ids[MAX_ID]; Hmm why would we need to keep an array of the non-booted socs? We know they're all false after booting.. A bitmask is usually used here? 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
[net-next PATCH v2] drivers: net: cpsw: Add support to make gpio drive which slave connected to phy
In DRA72x EVM, by default slave 1 is connected to the onboard phy, but slave 2 pins are also muxed with video input module which is controlled by pcf857x gpio and currently to select slave 0 to connect to phy gpio hogging is used, but with omap2plus_defconfig the pcf857x gpio is built as module. So when using NFS on DRA72x EVM, board doesn't boot as gpio hogging do not set proper gpio state to connect slave 0 to phy as it is built as module and you do not see any errors for not setting gpio and just mentions dhcp reply not got. To solve this issue, introducing "mode-gpio" in DT when gpio based muxing is required. This will throw a warning when gpio get fails and returns probe defer. When gpio-pcf857x module is installed, cpsw probes again and ethernet becomes functional. Verified this on DRA72x with pcf as module and ramdisk. Signed-off-by: Mugunthan V N--- Changes from initial version: * Updated the gpio dt naming to be more generic. This patch is texted on DRA72x, Logs [1] and pushed a branch [2] [1]: http://pastebin.ubuntu.com/12260767/ [2]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git cpsw-gpio-optional-v2 --- Documentation/devicetree/bindings/net/cpsw.txt | 7 +++ drivers/net/ethernet/ti/cpsw.c | 9 + 2 files changed, 16 insertions(+) diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt index 33fe846..dfe3e0b 100644 --- a/Documentation/devicetree/bindings/net/cpsw.txt +++ b/Documentation/devicetree/bindings/net/cpsw.txt @@ -26,6 +26,13 @@ Optional properties: - dual_emac: Specifies Switch to act as Dual EMAC - syscon : Phandle to the system control device node, which is the control module device of the am33x +- mode-gpio: Should be added if a gpio line is required to + be driven so that cpsw data lines can be + connected to the phy via selective mux. For + example in dra72x-evm, pcf gpio has to be + driven low so that cpsw slave 0 and phy + data lines are connected via mux. + Slave Properties: Required properties: diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c index 8fc90f1..90ae3f9 100644 --- a/drivers/net/ethernet/ti/cpsw.c +++ b/drivers/net/ethernet/ti/cpsw.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #include #include @@ -2207,6 +2208,7 @@ static int cpsw_probe(struct platform_device *pdev) void __iomem*ss_regs; struct resource *res, *ss_res; const struct of_device_id *of_id; + struct gpio_desc*mode; u32 slave_offset, sliver_offset, slave_size; int ret = 0, i; int irq; @@ -2232,6 +2234,13 @@ static int cpsw_probe(struct platform_device *pdev) goto clean_ndev_ret; } + mode = devm_gpiod_get_optional(>dev, "mode", GPIOD_OUT_LOW); + if (IS_ERR(mode)) { + ret = PTR_ERR(mode); + dev_err(>dev, "gpio request failed, ret %d\n", ret); + goto clean_ndev_ret; + } + /* * This may be required here for child devices. */ -- 2.5.1.522.g7aa67f6 -- 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/3] ARM: OMAP2+: clockdomain: Add mechanism for disabling HW_AUTO
On 28/07/15 14:34, Roger Quadros wrote: > Paul, > > On 16/07/15 16:56, Roger Quadros wrote: >> On 16/07/15 04:25, Paul Walmsley wrote: >>> Hi >>> >>> On Tue, 23 Jun 2015, Roger Quadros wrote: >>> For some hwmods (e.g. DCAN on DRA7) we need the possibility to disable HW_AUTO for the clockdomain while the module is active. To achieve this there needs to be a refcounting mechanism to indicate whether any module in the clockdomain has requested to disable HW_AUTO. We keep track of this in 'noidlecount'. Hwmod code must use clkdm_hwmod_prevent_hwauto() to prevent HW_AUTO of the clockdomain in the future clkdm_hwmod_hwauto() calls. It must use clkdm_hwmod_allow_hwauto() to allow HW_AUTO in the future clkdm_hwmod_hwauto() calls. Hwmod code must use clkdm_hwmod_allow_hwauto() whenever it needs to request HW_AUTO of any clockdomain. (Typically after it has enabled the module). >>> >>> How about just modifying clkdm_{allow,deny}_idle*() to do the >>> idle-block-counting? The default state would be to allow idle, assuming >>> that the clockdomain flags support that state, and then clkdm_deny_idle*() >>> would increment the idle-blocking count, clkdm_allow_idle*() would >>> decrement it. Then on the 0 -> 1 or 1 -> 0 transitions, the hardware >>> would be reprogrammed appropiately. >> >> That is not possible with current hwmod code as clkdm_allow_idle() and >> clkdm_deny_idle() >> are not symmetrically placed. >> >> The usual flow is >> clkdm_enable_hwmod(); >> if (hwsup) >> clkdm_allow_idle(); >> >> This is mainly because it is redundant to disable auto idle before enableing >> (SW_WKUP) the clockdomain. >> >> If we take your proposal above then we have to modify all users like so. >> >> if (hwsup) >> clkdm_deny_idle(); >> clkdm_enable_hwmod(); >> if (hwsup) >> clkdm_allow_idle(); >> >> Is this really what we want? > > Any comments on this? Paul. I'm waiting on your input to rework this series if needed. Early input would be much appreciated. Thanks. cheers, -roger > >> >>> >>> Anyway, seems like that would avoid races with any >>> clkdm_{allow,deny}_idle*() users. >>> >>> A few other comments below: >>> >>> Signed-off-by: Roger Quadros--- arch/arm/mach-omap2/clockdomain.c | 71 +++ arch/arm/mach-omap2/clockdomain.h | 5 +++ 2 files changed, 76 insertions(+) diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c index 2da3b5e..a7190d2 100644 --- a/arch/arm/mach-omap2/clockdomain.c +++ b/arch/arm/mach-omap2/clockdomain.c @@ -1212,6 +1212,77 @@ ccd_exit: return 0; } +/* + * prevent future hwauto for this clkdm. If clkdm->usecount becomes hwauto isn't prevented. + * It will only prevnt future hwauto but not bring it out of hwauto. + */ >>> >>> If you modify clkdm_{allow,deny}_idle*(), this shouldn't be a major issue >>> - but all of the function comments should be fixed so that they are >>> understandable and follow kernel-doc-nano specs. >> >> OK for updating the comments. >> >> >> cheers, >> -roger >> >>> +int clkdm_hwmod_prevent_hwauto(struct clockdomain *clkdm, struct omap_hwmod *oh) +{ + /* The clkdm attribute does not exist yet prior OMAP4 */ + if (cpu_is_omap24xx() || cpu_is_omap34xx()) + return 0; + + if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable) + return -EINVAL; + + + pwrdm_lock(clkdm->pwrdm.ptr); + clkdm->noidlecount++; + pwrdm_unlock(clkdm->pwrdm.ptr); + + return 0; +} + +/* + * allow future hwauto for this clkdm + * It won't put clkdm into hwauto. use clkdm_hwmod_hwauto() for that. + */ +int clkdm_hwmod_allow_hwauto(struct clockdomain *clkdm, struct omap_hwmod *oh) +{ + /* The clkdm attribute does not exist yet prior OMAP4 */ + if (cpu_is_omap24xx() || cpu_is_omap34xx()) + return 0; + + if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable) + return -EINVAL; + + + pwrdm_lock(clkdm->pwrdm.ptr); + + if (clkdm->noidlecount == 0) { + pwrdm_unlock(clkdm->pwrdm.ptr); + WARN_ON(1); /* underflow */ + return -ERANGE; + } + + clkdm->noidlecount--; + pwrdm_unlock(clkdm->pwrdm.ptr); + + return 0; +} + +/* + * put clkdm in hwauto if we can. checks noidlecount to see if we can. + */ +int clkdm_hwmod_hwauto(struct clockdomain *clkdm, struct omap_hwmod *oh) +{ + /* The clkdm attribute does not exist yet prior OMAP4 */ + if (cpu_is_omap24xx() || cpu_is_omap34xx()) +
Re: [PATCH] mtd: nand: omap2: Rename shippable module to omap2_nand
On 03/09/15 00:06, Brian Norris wrote: > On Fri, Aug 21, 2015 at 01:45:35PM +0300, Roger Quadros wrote: >> As both omap2 onenand and omap2 nand driver modules are >> named the same i.e. "omap2.ko", only one of them gets shipped >> during MODPOST if both are configured as loadable modules. >> >> To avoid this ambiguity let's ship the omap2 nand >> driver as "omap2_nand.ko" >> >> Reported by Pierre Neyron via github >> https://github.com/beagleboard/linux/issues/40 >> >> Cc: Robert Nelson>> Signed-off-by: Roger Quadros >> --- >> drivers/mtd/nand/Makefile | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile >> index 1f897ec..075a027 100644 >> --- a/drivers/mtd/nand/Makefile >> +++ b/drivers/mtd/nand/Makefile >> @@ -26,7 +26,8 @@ obj-$(CONFIG_MTD_NAND_CS553X) += cs553x_nand.o >> obj-$(CONFIG_MTD_NAND_NDFC) += ndfc.o >> obj-$(CONFIG_MTD_NAND_ATMEL)+= atmel_nand.o >> obj-$(CONFIG_MTD_NAND_GPIO) += gpio.o >> -obj-$(CONFIG_MTD_NAND_OMAP2)+= omap2.o >> +omap2_nand-objs := omap2.o >> +obj-$(CONFIG_MTD_NAND_OMAP2)+= omap2_nand.o > > Pushed to l2-mtd.git. I suppose this one should go out for 4.3, as > there's little downside to it, and it's kind of a bugfix. That is perfectly fine. Thanks. cheers, -roger > >> obj-$(CONFIG_MTD_NAND_OMAP_BCH_BUILD) += omap_elm.o >> obj-$(CONFIG_MTD_NAND_CM_X270) += cmx270_nand.o >> obj-$(CONFIG_MTD_NAND_PXA3xx) += pxa3xx_nand.o >> -- >> 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
[PATCH v2 1/6] regulator: pbias: program pbias register offset in pbias driver
Add separate compatible strings for every platform and populate the pbias register offset in the driver data. This helps avoid depending on the dt for pbias register offset. Also update the dt binding documentation for the new compatible strings. Suggested-by: Tony LindgrenSigned-off-by: Kishon Vijay Abraham I Acked-by: Tony Lindgren --- .../bindings/regulator/pbias-regulator.txt |7 ++- drivers/regulator/pbias-regulator.c| 56 +--- 2 files changed, 56 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt index 32aa26f..acbcb45 100644 --- a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt @@ -2,7 +2,12 @@ PBIAS internal regulator for SD card dual voltage i/o pads on OMAP SoCs. Required properties: - compatible: - - "ti,pbias-omap" for OMAP2, OMAP3, OMAP4, OMAP5, DRA7. + - should be "ti,pbias-dra7" for DRA7 + - should be "ti,pbias-omap2" for OMAP2 + - should be "ti,pbias-omap3" for OMAP3 + - should be "ti,pbias-omap4" for OMAP4 + - should be "ti,pbias-omap5" for OMAP5 + - "ti,pbias-omap" is deprecated - reg: pbias register offset from syscon base and size of pbias register. - syscon : phandle of the system control module - regulator-name : should be diff --git a/drivers/regulator/pbias-regulator.c b/drivers/regulator/pbias-regulator.c index bd2b75c..c21cedb 100644 --- a/drivers/regulator/pbias-regulator.c +++ b/drivers/regulator/pbias-regulator.c @@ -44,6 +44,10 @@ struct pbias_regulator_data { int voltage; }; +struct pbias_of_data { + unsigned int offset; +}; + static const unsigned int pbias_volt_table[] = { 180, 300 @@ -98,8 +102,35 @@ static struct of_regulator_match pbias_matches[] = { }; #define PBIAS_NUM_REGS ARRAY_SIZE(pbias_matches) +/* Offset from SCM general area (and syscon) base */ + +static const struct pbias_of_data pbias_of_data_omap2 = { + .offset = 0x230, +}; + +static const struct pbias_of_data pbias_of_data_omap3 = { + .offset = 0x2b0, +}; + +static const struct pbias_of_data pbias_of_data_omap4 = { + .offset = 0x60, +}; + +static const struct pbias_of_data pbias_of_data_omap5 = { + .offset = 0x60, +}; + +static const struct pbias_of_data pbias_of_data_dra7 = { + .offset = 0xe00, +}; + static const struct of_device_id pbias_of_match[] = { { .compatible = "ti,pbias-omap", }, + { .compatible = "ti,pbias-omap2", .data = _of_data_omap2, }, + { .compatible = "ti,pbias-omap3", .data = _of_data_omap3, }, + { .compatible = "ti,pbias-omap4", .data = _of_data_omap4, }, + { .compatible = "ti,pbias-omap5", .data = _of_data_omap5, }, + { .compatible = "ti,pbias-dra7", .data = _of_data_dra7, }, {}, }; MODULE_DEVICE_TABLE(of, pbias_of_match); @@ -114,6 +145,9 @@ static int pbias_regulator_probe(struct platform_device *pdev) const struct pbias_reg_info *info; int ret = 0; int count, idx, data_idx = 0; + const struct of_device_id *match; + const struct pbias_of_data *data; + unsigned int offset; count = of_regulator_match(>dev, np, pbias_matches, PBIAS_NUM_REGS); @@ -129,6 +163,20 @@ static int pbias_regulator_probe(struct platform_device *pdev) if (IS_ERR(syscon)) return PTR_ERR(syscon); + match = of_match_device(of_match_ptr(pbias_of_match), >dev); + if (match && match->data) { + data = match->data; + offset = data->offset; + } else { + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (!res) + return -EINVAL; + + offset = res->start; + dev_WARN(>dev, +"using legacy dt data for pbias offset\n"); + } + cfg.regmap = syscon; cfg.dev = >dev; @@ -141,10 +189,6 @@ static int pbias_regulator_probe(struct platform_device *pdev) if (!info) return -ENODEV; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) - return -EINVAL; - drvdata[data_idx].syscon = syscon; drvdata[data_idx].info = info; drvdata[data_idx].desc.name = info->name; @@ -154,9 +198,9 @@ static int pbias_regulator_probe(struct platform_device *pdev) drvdata[data_idx].desc.volt_table = pbias_volt_table; drvdata[data_idx].desc.n_voltages = 2; drvdata[data_idx].desc.enable_time = info->enable_time; - drvdata[data_idx].desc.vsel_reg = res->start; +
[PATCH v2 0/6] regulator: Fix pbias regulator enable
vsel_reg and enable_reg of the pbias regulator descriptor should actually have the offset from syscon. However after "ARM: dts: : add minimal l4 bus layout with control module support" vsel_reg and enable_reg started to have the absolute address because of address translation that happens due to pbias node made as the child node of syscon. This breaks the pbias regulator enable. This series adds the 'offset' to be populated in vsel_reg and enable_reg in the pbias driver itself. Changes from v1: *) Fixed Tony's review comments on adding a 'comment' for adding offset in the driver and adding a warning for using platform_get_resource. *) Added Tony's Acked-by. Tested these patches against mmc -next in omap4 panda, omap3 beagle xm, dra72 and omap5 uevm Kishon Vijay Abraham I (6): regulator: pbias: program pbias register offset in pbias driver ARM: dts: dra7: use "ti,pbias-dra7" compatible string for pbias ARM: dts: omap243x: use "ti,pbias-omap2" compatible string for pbias ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias ARM: dts: omap4: use "ti,pbias-omap4" compatible string for pbias ARM: dts: omap5: use "ti,pbias-omap5" compatible string for pbias .../bindings/regulator/pbias-regulator.txt |7 ++- arch/arm/boot/dts/dra7.dtsi|2 +- arch/arm/boot/dts/omap2430.dtsi|2 +- arch/arm/boot/dts/omap3.dtsi |2 +- arch/arm/boot/dts/omap4.dtsi |2 +- arch/arm/boot/dts/omap5.dtsi |2 +- drivers/regulator/pbias-regulator.c| 56 +--- 7 files changed, 61 insertions(+), 12 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/6] ARM: dts: dra7: use "ti,pbias-dra7" compatible string for pbias
Use "ti,pbias-dra7" compatible string which is specifically added for DRA7 SoCs. Signed-off-by: Kishon Vijay Abraham IAcked-by: Tony Lindgren --- arch/arm/boot/dts/dra7.dtsi |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 1e29ccf..d6bc6db 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -122,7 +122,7 @@ #size-cells = <1>; pbias_regulator: pbias_regulator { - compatible = "ti,pbias-omap"; + compatible = "ti,pbias-dra7", "ti,pbias-omap"; reg = <0xe00 0x4>; syscon = <_conf>; pbias_mmc_reg: pbias_mmc_omap5 { -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/6] ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias
Use "ti,pbias-omap3" compatible string which is specifically added for OMAP3. Signed-off-by: Kishon Vijay Abraham IAcked-by: Tony Lindgren --- arch/arm/boot/dts/omap3.dtsi |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi index 69a40cf..9af9ae1 100644 --- a/arch/arm/boot/dts/omap3.dtsi +++ b/arch/arm/boot/dts/omap3.dtsi @@ -203,7 +203,7 @@ }; pbias_regulator: pbias_regulator { - compatible = "ti,pbias-omap"; + compatible = "ti,pbias-omap3", "ti,pbias-omap"; reg = <0x2b0 0x4>; syscon = <_conf>; pbias_mmc_reg: pbias_mmc_omap2430 { -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/6] ARM: dts: omap243x: use "ti,pbias-omap2" compatible string for pbias
Use "ti,pbias-omap2" compatible string which is specifically added for OMAP2. Signed-off-by: Kishon Vijay Abraham IAcked-by: Tony Lindgren --- arch/arm/boot/dts/omap2430.dtsi |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi index 2390f38..3961a6f 100644 --- a/arch/arm/boot/dts/omap2430.dtsi +++ b/arch/arm/boot/dts/omap2430.dtsi @@ -63,7 +63,7 @@ }; pbias_regulator: pbias_regulator { - compatible = "ti,pbias-omap"; + compatible = "ti,pbias-omap2", "ti,pbias-omap"; reg = <0x230 0x4>; syscon = <_conf>; pbias_mmc_reg: pbias_mmc_omap2430 { -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] regulator: Fix pbias regulator enable
Hi, On Thursday 03 September 2015 01:09 PM, Ulf Hansson wrote: > +Olof > > On 3 September 2015 at 08:50, Kishon Vijay Abraham Iwrote: >> vsel_reg and enable_reg of the pbias regulator descriptor should actually >> have the offset from syscon. >> >> However after >> "ARM: dts: : add minimal l4 bus layout with control module >> support" >> vsel_reg and enable_reg started to have the absolute address because >> of address translation that happens due to pbias node made as the >> child node of syscon. This breaks the pbias regulator enable. >> >> This series adds the 'offset' to be populated in vsel_reg and enable_reg >> in the pbias driver itself. >> >> Changes from v1: >> *) Fixed Tony's review comments on adding a 'comment' for adding offset in >>the driver and adding a warning for using platform_get_resource. >> *) Added Tony's Acked-by. >> >> Tested these patches against mmc -next in omap4 panda, omap3 beagle xm, >> dra72 and omap5 uevm >> >> Kishon Vijay Abraham I (6): >> regulator: pbias: program pbias register offset in pbias driver >> ARM: dts: dra7: use "ti,pbias-dra7" compatible string for pbias >> ARM: dts: omap243x: use "ti,pbias-omap2" compatible string for pbias >> ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias >> ARM: dts: omap4: use "ti,pbias-omap4" compatible string for pbias >> ARM: dts: omap5: use "ti,pbias-omap5" compatible string for pbias >> >> .../bindings/regulator/pbias-regulator.txt |7 ++- >> arch/arm/boot/dts/dra7.dtsi|2 +- >> arch/arm/boot/dts/omap2430.dtsi|2 +- >> arch/arm/boot/dts/omap3.dtsi |2 +- >> arch/arm/boot/dts/omap4.dtsi |2 +- >> arch/arm/boot/dts/omap5.dtsi |2 +- >> drivers/regulator/pbias-regulator.c| 56 >> +--- >> 7 files changed, 61 insertions(+), 12 deletions(-) >> >> -- >> 1.7.9.5 >> > > I have recently queued another patchset [1] for the mmc omap driver > for 4.3 through my mmc tree for which Olof Johansson reported a > regression [2] for Panda ES with multi_v7_defconfig. I generally perform my tests with omap2plus_defconfig and without this series MMC doesn't work with omap2plus_defconfig. > > Kishon, could you please clarify if $subject patchset solves that > regression reported by Olof? Or perhaps Olof can run a test? Just checked multi_v7_defconfig and this series is definitely required to get MMC working. But we also have to enable 'CONFIG_REGULATOR_PBIAS' which is not enabled by default in multi_v7_defconfig. So we should have a patch to enable 'CONFIG_REGULATOR_PBIAS' in multi_v7_defconfig to completely solve the problem reported by Olof. I'll prepare a patch for multi_v7_defconfig and post it asap. Thanks Kishon > > Finally, perhaps it's better if we queue this through my mmc tree > since we would then be able to avoid the regression - if I put > $subject patchset before [1], right? Then I need an ack from Mark for > the regulator patch. > Please tell me if you guys prefer another way. > > Kind regards > Uffe > > [1] > http://permalink.gmane.org/gmane.linux.kernel/2027789 > > [2] > http://www.spinics.net/lists/linux-mmc/msg33146.html > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/6] ARM: dts: omap5: use "ti,pbias-omap5" compatible string for pbias
Use "ti,pbias-omap5" compatible string which is specifically added for OMAP5. Signed-off-by: Kishon Vijay Abraham IAcked-by: Tony Lindgren --- arch/arm/boot/dts/omap5.dtsi |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index b1a1263..76ef595 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -187,7 +187,7 @@ #size-cells = <1>; pbias_regulator: pbias_regulator { - compatible = "ti,pbias-omap"; + compatible = "ti,pbias-omap5", "ti,pbias-omap"; reg = <0x60 0x4>; syscon = <_padconf_global>; pbias_mmc_reg: pbias_mmc_omap5 { -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/6] ARM: dts: omap4: use "ti,pbias-omap4" compatible string for pbias
Use "ti,pbias-omap4" compatible string which is specifically added for OMAP4. Signed-off-by: Kishon Vijay Abraham IAcked-by: Tony Lindgren --- arch/arm/boot/dts/omap4.dtsi |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index abc4473..5aad7f3 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -198,7 +198,7 @@ #size-cells = <1>; pbias_regulator: pbias_regulator { - compatible = "ti,pbias-omap"; + compatible = "ti,pbias-omap4", "ti,pbias-omap"; reg = <0x60 0x4>; syscon = <_padconf_global>; pbias_mmc_reg: pbias_mmc_omap4 { -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: dts: am57xx-beagle-x15: use palmas-usb for USB2
Chanwoo, On 06/08/15 02:36, Chanwoo Choi wrote: > On 08/05/2015 07:37 PM, Tony Lindgren wrote: >> * Roger Quadros[150727 06:13]: >>> The VBUS line of USB2 is connected to VBUS detect logic on >>> the PMIC. Use the palmas-usb driver to report VBUS events >>> to the USB driver. >>> >>> As the palmas-usb driver supports GPIO based ID reporting >>> provide the GPIO for ID pin as well. >>> >>> Signed-off-by: Roger Quadros >> >> This should not cause merge conflicts with what I have queeud >> for v4.3, so Chanwoo please feel free to apply with the rest >> of the extcon series: >> >> Acked-by: Tony Lindgren >> > > I reviewd this patchset related to extcon and give the acked-by message. > but patch1 must need the acked-by message from MFD maintainer. > > If patch1 receive the acked-by message from MFD maintainer, > I'll apply it for v4.3. > > Roger, > I think that you better to recevie the acked-by message before v4.2-rc6 > release. > I have the plan about pull request of extcon for v4.3 after v4.2-rc6 releas. Seems like you picked patch 1 but not this one. As Tony has already Acked it can you please include patch 2 as well in your tree for -next? Thanks. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] regulator: Fix pbias regulator enable
+Olof On 3 September 2015 at 08:50, Kishon Vijay Abraham Iwrote: > vsel_reg and enable_reg of the pbias regulator descriptor should actually > have the offset from syscon. > > However after > "ARM: dts: : add minimal l4 bus layout with control module > support" > vsel_reg and enable_reg started to have the absolute address because > of address translation that happens due to pbias node made as the > child node of syscon. This breaks the pbias regulator enable. > > This series adds the 'offset' to be populated in vsel_reg and enable_reg > in the pbias driver itself. > > Changes from v1: > *) Fixed Tony's review comments on adding a 'comment' for adding offset in >the driver and adding a warning for using platform_get_resource. > *) Added Tony's Acked-by. > > Tested these patches against mmc -next in omap4 panda, omap3 beagle xm, > dra72 and omap5 uevm > > Kishon Vijay Abraham I (6): > regulator: pbias: program pbias register offset in pbias driver > ARM: dts: dra7: use "ti,pbias-dra7" compatible string for pbias > ARM: dts: omap243x: use "ti,pbias-omap2" compatible string for pbias > ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias > ARM: dts: omap4: use "ti,pbias-omap4" compatible string for pbias > ARM: dts: omap5: use "ti,pbias-omap5" compatible string for pbias > > .../bindings/regulator/pbias-regulator.txt |7 ++- > arch/arm/boot/dts/dra7.dtsi|2 +- > arch/arm/boot/dts/omap2430.dtsi|2 +- > arch/arm/boot/dts/omap3.dtsi |2 +- > arch/arm/boot/dts/omap4.dtsi |2 +- > arch/arm/boot/dts/omap5.dtsi |2 +- > drivers/regulator/pbias-regulator.c| 56 > +--- > 7 files changed, 61 insertions(+), 12 deletions(-) > > -- > 1.7.9.5 > I have recently queued another patchset [1] for the mmc omap driver for 4.3 through my mmc tree for which Olof Johansson reported a regression [2] for Panda ES with multi_v7_defconfig. Kishon, could you please clarify if $subject patchset solves that regression reported by Olof? Or perhaps Olof can run a test? Finally, perhaps it's better if we queue this through my mmc tree since we would then be able to avoid the regression - if I put $subject patchset before [1], right? Then I need an ack from Mark for the regulator patch. Please tell me if you guys prefer another way. Kind regards Uffe [1] http://permalink.gmane.org/gmane.linux.kernel/2027789 [2] http://www.spinics.net/lists/linux-mmc/msg33146.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: multi_v7_defconfig: Enable PBIAS regulator
PBIAS regulator is required for MMC module in OMAP2, OMAP3, OMAP4, OMAP5 and DRA7 SoCs. Enable it here. Signed-off-by: Kishon Vijay Abraham I--- arch/arm/configs/multi_v7_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 5fd8df6..f497c96 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -403,6 +403,7 @@ CONFIG_REGULATOR_MAX8973=y CONFIG_REGULATOR_MAX77686=y CONFIG_REGULATOR_MAX77693=m CONFIG_REGULATOR_PALMAS=y +CONFIG_REGULATOR_PBIAS=y CONFIG_REGULATOR_S2MPS11=y CONFIG_REGULATOR_S5M8767=y CONFIG_REGULATOR_TPS51632=y -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Myir AM437x Rico board support for Linux 4.1 kernel
+Tony, Tomi, linux-omap Hi Pavel, On 25/08/15 16:39, Pavel Pisa wrote: > Hello everybody, > > I have been asked to help with Linux on Myir Rico board. > I have decided to try actual stable kernel from Ti tree > > git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git > branch ti-linux-4.1.y > > instead of delivered dated 3.12.10 one to solve some issues > and have chance to port possible enhancements to mainline. > > I have successfully prepared environment which loads kernel > over TFTP and boot actual Debian Jessie armhf from NFS export. > > Because I have not found up to date device tree for this > board I have analyzed delivered sources against best matching > Ti kernel and then prepared DTS which works on the board > and I want to know if somebody works on this support, can help > to finish/better tune parameters and if there is chance > that configs are included into mainline or some other public > repository. Because I do not know who is working on this support > and who is right maintainer I send only pointers to my files. Tony Lindgren is the OMAP platform maintainer and you must include linux-omap mailing list in in the discussion. > > http://cmp.felk.cvut.cz/~pisa/arm/myir-rico/am437x-myir-ricoboard.dts > based on Ti am437x-gp-evm.dts > > http://cmp.felk.cvut.cz/~pisa/arm/myir-rico/am437x-myir-ricoboard-hdmi.dts > based on Ti am437x-gp-evm-hdmi.dts > > http://cmp.felk.cvut.cz/~pisa/arm/myir-rico/am437x-myir-ricoboard_defconfig > > If there is interrest for discussion and inclusion, I send usual > inlined GIT patches series. Please send patches for the new board so that we can review. > > As for DTS, I expect that the regulators section does not match correctly > Rico board HW but it works for what client company needs > evm_v3_3d: fixedregulator-v3_3d > vtt_fixed: fixedregulator-vtt > > Ethernet, serials, cameras, local MTD, SDcard and most of other devices works. > SPI Flash does not work. I have not invested time to that. > > The client needs to connect special camera (infrared) to the VPFE so I have > spent some time on AM437x VPFE support enhancement. > > I have added V4L2_PIX_FMT_Y10 pixel format and some minimal/stub > implementation of vpfe_enum_frameintervals, vpfe_g_parm, vvpfe_s_parm, > pfe_s_parm and I would be happy if my work can help to somebody other > as well. But work has been driven strict deadline to provide working > solution in one week so if there is interrest then most has to be > rewritten/clean up. > > Generally, I am quite pleased by Ti's Linux tree state and support. > That week has been my first time with AM chips we used other archs > (powerpc and multiple i.MXs for most of our other projects till now). > > Probably off topic for these lists but what are suggested options > for graphic configuration when Qt4/E or Qt5 is run on framebuffer. > Is it better to use CONFIG_DRM_OMAP or CONFIG_FB_OMAP2 ? > Is SGX driver available for 4.1 Linux kernel (reply offlist, please, > if proprietary only)? Are there other possibilities how to use > OMAP AM437xx hardware to accelerate video color and formats > transformations? Can be VPFE planes used somehow to embed > video in Qt application? I, personally, prefer strongly > opensource only options but target company has probably minimal > requirements in this area. Tomi might be able to answer video related questions. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: dts: omap24xx: fix address translation for pbias
commit <72b10ac00eb1> ("ARM: dts: omap24xx: add minimal l4 bus layout with control module support") moved pbias_regulator dt node from being a child node of ocp to be the child node of scm_conf. Since scm_conf doesn't have the 'ranges' property, address translation fails while trying to convert the address to resource. Fix it here. Fixes: 72b10ac00eb1 ("ARM: dts: omap24xx: add minimal l4 bus layout with control module support") Signed-off-by: Kishon Vijay Abraham I--- arch/arm/boot/dts/omap2430.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi index 3961a6f..798dda0 100644 --- a/arch/arm/boot/dts/omap2430.dtsi +++ b/arch/arm/boot/dts/omap2430.dtsi @@ -56,6 +56,7 @@ reg = <0x270 0x240>; #address-cells = <1>; #size-cells = <1>; + ranges = <0 0x270 0x240>; scm_clocks: clocks { #address-cells = <1>; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: dts: dra7: fix address translation for pbias
commit ("ARM: dts: dra7: add minimal l4 bus layout with control module support") moved pbias_regulator dt node from being a child node of ocp to be the child node of scm_conf. Since scm_conf doesn't have the 'ranges' property, address translation fails while trying to convert the address to resource. Fix it here. Fixes: d919501feffa ("ARM: dts: dra7: add minimal l4 bus layout with control module support") Signed-off-by: Kishon Vijay Abraham I--- arch/arm/boot/dts/dra7.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index d6bc6db..5896896 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -120,6 +120,7 @@ reg = <0x0 0x1400>; #address-cells = <1>; #size-cells = <1>; + ranges = <0 0x0 0x1400>; pbias_regulator: pbias_regulator { compatible = "ti,pbias-dra7", "ti,pbias-omap"; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] omap: Fix broken address translation for pbias
pbias device stopped having memory resource after "ARM: dts: : add minimal l4 bus layout with control module support" got merged. This results in platform_get_resource returning -EINVAL in pbias driver. This is because address translation fails while trying to convert the address to resource which happens during the device creation process during boot up. Even though after [1], reg property in pbias dt node is un-used, it might be an issue if we plan to use it at a later point of time. Patch series is created on top of [1]. [1] -> https://lkml.org/lkml/2015/9/3/51 Verified the address in omap4 panda, omap5 uevm and dra72 boards. Kishon Vijay Abraham I (4): ARM: dts: omap24xx: fix address translation for pbias ARM: dts: omap4: fix address translation for pbias ARM: dts: omap5: fix address translation for pbias ARM: dts: dra7: fix address translation for pbias arch/arm/boot/dts/dra7.dtsi |1 + arch/arm/boot/dts/omap2430.dtsi |1 + arch/arm/boot/dts/omap4.dtsi|1 + arch/arm/boot/dts/omap5.dtsi|1 + 4 files changed, 4 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: am335x-phycore-som: Fix mpu voltage
Fix the mpu voltage as it is set to low for the silicon revision 2.1. Signed-off-by: Teresa Remmet--- arch/arm/boot/dts/am335x-phycore-som.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi b/arch/arm/boot/dts/am335x-phycore-som.dtsi index 4d28fc3..5dd084f 100644 --- a/arch/arm/boot/dts/am335x-phycore-som.dtsi +++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi @@ -252,10 +252,10 @@ }; vdd1_reg: regulator@2 { - /* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */ + /* VDD_MPU voltage limits 0.95V - 1.325V with +/-4% tolerance */ regulator-name = "vdd_mpu"; regulator-min-microvolt = <912500>; - regulator-max-microvolt = <1312500>; + regulator-max-microvolt = <1378000>; regulator-boot-on; regulator-always-on; }; -- 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 v4 1/9] usb: dwc3: add dual-role support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/15 17:31, Felipe Balbi wrote: > Hi, > > On Wed, Sep 02, 2015 at 05:24:16PM +0300, Roger Quadros wrote: >> Register with the USB OTG core. Since we don't support >> OTG yet we just work as a dual-role device even >> if device tree says "otg". >> >> Use extcon framework to get VBUS/ID cable events and >> kick the OTG state machine. >> >> Signed-off-by: Roger Quadros>> --- >> drivers/usb/dwc3/core.c | 174 >> ++- >> drivers/usb/dwc3/core.h | 7 ++ >> drivers/usb/dwc3/platform_data.h | 1 + >> 3 files changed, 181 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c >> index 064123e..2e36a9b 100644 >> --- a/drivers/usb/dwc3/core.c >> +++ b/drivers/usb/dwc3/core.c >> @@ -704,6 +704,152 @@ static int dwc3_core_get_phy(struct dwc3 *dwc) >> return 0; >> } >> >> +/* - Dual-Role management >> --- */ >> + >> +static void dwc3_drd_fsm_sync(struct dwc3 *dwc) >> +{ >> +int id, vbus; >> + >> +/* get ID */ >> +id = extcon_get_cable_state(dwc->edev, "USB-HOST"); >> +/* Host means ID == 0 */ >> +id = !id; >> + >> +/* get VBUS */ >> +vbus = extcon_get_cable_state(dwc->edev, "USB"); >> +dev_dbg(dwc->dev, "id %d vbus %d\n", id, vbus); > > tracepoint please. We don't want this driver to use dev_(v)?db anymore. > Ditto to all others. OK. > >> + >> +dwc->fsm->id = id; >> +dwc->fsm->b_sess_vld = vbus; >> +usb_otg_sync_inputs(dwc->fsm); >> +} >> + >> +static int dwc3_drd_start_host(struct otg_fsm *fsm, int on) >> +{ >> +struct device *dev = usb_otg_fsm_to_dev(fsm); >> +struct dwc3 *dwc = dev_get_drvdata(dev); > > how about adding a usb_otg_get_drvdata(fsm) ? You meant for otg core? That can be done. > >> +dev_dbg(dwc->dev, "%s: %d\n", __func__, on); >> +if (on) { >> +dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST); >> +/* start the HCD */ >> +usb_otg_start_host(fsm, true); >> +} else { >> +/* stop the HCD */ >> +usb_otg_start_host(fsm, false); >> +} > > This can be simplified. > > if (on) > dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST); > > usb_otg_start_host(fsm, on); Indeed. > >> + >> +return 0; >> +} >> + >> +static int dwc3_drd_start_gadget(struct otg_fsm *fsm, int on) >> +{ >> +struct device *dev = usb_otg_fsm_to_dev(fsm); >> +struct dwc3 *dwc = dev_get_drvdata(dev); >> + >> +dev_dbg(dwc->dev, "%s: %d\n", __func__, on); >> +if (on) { >> +dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE); >> +dwc3_event_buffers_setup(dwc); >> + >> +/* start the UDC */ >> +usb_otg_start_gadget(fsm, true); >> +} else { >> +/* stop the UDC */ >> +usb_otg_start_gadget(fsm, false); >> +} > > likewise: > > if (on) { > dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE); > dwc3_event_buffers_setup(dwc); > } > > usb_otg_start_gadget(fsm, on); OK. > >> +return 0; >> +} >> + >> +static struct otg_fsm_ops dwc3_drd_ops = { >> +.start_host = dwc3_drd_start_host, >> +.start_gadget = dwc3_drd_start_gadget, >> +}; >> + >> +static int dwc3_drd_notifier(struct notifier_block *nb, >> + unsigned long event, void *ptr) >> +{ >> +struct dwc3 *dwc = container_of(nb, struct dwc3, otg_nb); >> + >> +dwc3_drd_fsm_sync(dwc); >> + >> +return NOTIFY_DONE; >> +} >> + >> +static int dwc3_drd_init(struct dwc3 *dwc) >> +{ >> +int ret, id, vbus; >> +struct usb_otg_caps *otgcaps = >otg_config.otg_caps; >> + >> +otgcaps->otg_rev = 0; >> +otgcaps->hnp_support = false; >> +otgcaps->srp_support = false; >> +otgcaps->adp_support = false; >> +dwc->otg_config.fsm_ops = _drd_ops; >> + >> +if (!dwc->edev) { >> +dev_err(dwc->dev, "No extcon device found for OTG mode\n"); >> +return -ENODEV; >> +} >> + >> +dwc->otg_nb.notifier_call = dwc3_drd_notifier; >> +ret = extcon_register_notifier(dwc->edev, EXTCON_USB, >otg_nb); >> +if (ret < 0) { >> +dev_err(dwc->dev, "Couldn't register USB cable notifier\n"); >> +return -ENODEV; >> +} >> + >> +ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST, >> + >otg_nb); >> +if (ret < 0) { >> +dev_err(dwc->dev, "Couldn't register USB-HOST cable >> notifier\n"); >> +ret = -ENODEV; >> +goto extcon_fail; >> +} >> + >> +/* sanity check id & vbus states */ >> +id = extcon_get_cable_state(dwc->edev, "USB-HOST"); >> +vbus = extcon_get_cable_state(dwc->edev, "USB"); >> +if (id < 0 || vbus < 0) { >> +dev_err(dwc->dev, "Invalid USB cable state. id %d, vbus %d\n", >> +
[PATCH 3/4] ARM: dts: omap5: fix address translation for pbias
commit ("ARM: dts: omap5: add minimal l4 bus layout with control module support") moved pbias_regulator dt node from being a child node of ocp to be the child node of omap5_padconf_global. Since omap5_padconf_global doesn't have the 'ranges' property, address translation fails while trying to convert the address to resource. Fix it here. Fixes: ed8509edddeb ("ARM: dts: omap5: add minimal l4 bus layout with control module support") Signed-off-by: Kishon Vijay Abraham I--- arch/arm/boot/dts/omap5.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 76ef595..dd7a0e8 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -185,6 +185,7 @@ reg = <0x5a0 0xec>; #address-cells = <1>; #size-cells = <1>; + ranges = <0 0x5a0 0xec>; pbias_regulator: pbias_regulator { compatible = "ti,pbias-omap5", "ti,pbias-omap"; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: dts: omap4: fix address translation for pbias
commit <7415b0b4c645> ("ARM: dts: omap4: add minimal l4 bus layout with control module support") moved pbias_regulator dt node from being a child node of ocp to be the child node of omap4_padconf_global. Since omap4_padconf_global doesn't have the 'ranges' property, address translation fails while trying to convert the address to resource. Fix it here. Fixes: 7415b0b4c645 ("ARM: dts: omap4: add minimal l4 bus layout with control module support") Signed-off-by: Kishon Vijay Abraham I--- arch/arm/boot/dts/omap4.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 5aad7f3..5a206c1 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -196,6 +196,7 @@ reg = <0x5a0 0x170>; #address-cells = <1>; #size-cells = <1>; + ranges = <0 0x5a0 0x170>; pbias_regulator: pbias_regulator { compatible = "ti,pbias-omap4", "ti,pbias-omap"; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: am335x-wega: Clean up regulators
Cleaned up the regulators on the wega board. Created a simple bus, renamed the regulators according to the schematics and added missing regulator on wega. Signed-off-by: Teresa Remmet--- arch/arm/boot/dts/am335x-phycore-som.dtsi | 36 --- arch/arm/boot/dts/am335x-wega.dtsi| 13 ++- 2 files changed, 31 insertions(+), 18 deletions(-) diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi b/arch/arm/boot/dts/am335x-phycore-som.dtsi index 5dd084f..2f43e45 100644 --- a/arch/arm/boot/dts/am335x-phycore-som.dtsi +++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi @@ -29,8 +29,17 @@ reg = <0x8000 0x1000>; /* 256 MB */ }; - vbat: fixedregulator@0 { - compatible = "regulator-fixed"; + regulators { + compatible = "simple-bus"; + + vcc5v: fixedregulator@0 { + compatible = "regulator-fixed"; + regulator-name = "vcc5v"; + regulator-min-microvolt = <500>; + regulator-max-microvolt = <500>; + regulator-boot-on; + regulator-always-on; + }; }; }; @@ -233,14 +242,14 @@ #include "tps65910.dtsi" { - vcc1-supply = <>; - vcc2-supply = <>; - vcc3-supply = <>; - vcc4-supply = <>; - vcc5-supply = <>; - vcc6-supply = <>; - vcc7-supply = <>; - vccio-supply = <>; + vcc1-supply = <>; + vcc2-supply = <>; + vcc3-supply = <>; + vcc4-supply = <>; + vcc5-supply = <>; + vcc6-supply = <>; + vcc7-supply = <>; + vccio-supply = <>; regulators { vrtc_reg: regulator@0 { @@ -311,13 +320,6 @@ }; }; - { - regulator-name = "vbat"; - regulator-min-microvolt = <500>; - regulator-max-microvolt = <500>; - regulator-boot-on; -}; - /* SPI Busses */ _pinmux { spi0_pins: pinmux_spi0 { diff --git a/arch/arm/boot/dts/am335x-wega.dtsi b/arch/arm/boot/dts/am335x-wega.dtsi index 5e541bd..2cecb39 100644 --- a/arch/arm/boot/dts/am335x-wega.dtsi +++ b/arch/arm/boot/dts/am335x-wega.dtsi @@ -11,6 +11,17 @@ model = "Phytec AM335x phyBOARD-WEGA"; compatible = "phytec,am335x-wega", "phytec,am335x-phycore-som", "ti,am33xx"; + regulators { + compatible = "simple-bus"; + + vcc3v3: fixedregulator@1 { + compatible = "regulator-fixed"; + regulator-name = "vcc3v3"; + regulator-min-microvolt = <330>; + regulator-max-microvolt = <330>; + regulator-boot-on; + }; + }; }; /* CAN Busses */ @@ -80,7 +91,7 @@ }; { - vmmc-supply = <_reg>; + vmmc-supply = <>; bus-width = <4>; pinctrl-names = "default"; pinctrl-0 = <_pins>; -- 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 1/2] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation
Hi Sakari, On 07/16/2015 07:58 AM, Tony Lindgren wrote: > * Laurent Pinchart[150716 05:57]: >> The OMAP3 ISP is now fully supported in DT, remove its instantiation >> from C code. > > Please feel to queue this along with the second patch in this series, > this should not cause any merge conflicts: > > Acked-by: Tony Lindgren Just wondering if you have already queued this, I see the v4l changes in linux-next, but not this patch. Also, can you confirm if this series is making it into 4.3? regards Suman -- 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] iommu/omap: Add support for configuring dsp iommus on DRA7xx
Hi Tony, Sorry for the long delay in getting back on this. I will repost the series once 4.3-rc1 is out, but at the moment I do not think any changes are required. Let me know if you still need any additional details. On 07/23/2015 02:24 AM, Tony Lindgren wrote: > * Suman Anna[150722 09:25]: >> On 07/22/2015 12:26 AM, Tony Lindgren wrote: >>> >>> I don't like using syscon for tinkering directly with SoC registers. >> >> This is not a SoC-level register, but a register within a sub-module of >> the DSP processor sub-system. The DSP_SYSTEM sub-module in general is >> described in Section 5.3.3 of the TRM [1], and it implements different >> functionalities like the PRCM handshaking, wakeup logic and DSP >> subsystem top-level configuration. It is a module present within the DSP >> processor sub-system, so can only be accessed when the sub-system is >> clocked and the appropriate reset is released. > > OK so if it's specific to the DSP driver along the lines of sysc and > syss registers. There will be those registers too within the MMU config register space, even for DRA7xx MMUs. This is different, think of it like a register in the Control module except that it is present within the DSP sub-system instead of at the SoC level. >>> >>> And what is taking care of pm_runtime_get here to ensure the module >>> is powered and clocked? >> >> pm_runtime_get_sync is indeed getting invoked, its just the current >> patch doesn't include the code block that invokes it. The function that >> invokes omap2_iommu_enable does so after a call to the >> pm_runtime_get_sync() call. > > OK > >>> I think you are missing a layer here and it's the Linux kernel side >>> device driver for DSP that initializes things. >> >> We already have separate drivers for MMUs (omap-iommu) and the processor >> management (omap-rproc). The former manages all the low-level >> programming sequences for the MMUs, while the latter manages the >> low-level reset etc, and is a client user of the respective IOMMU >> device. Both integrate into the respective frameworks. The IOMMU API >> invocations are handled in the remoteproc core, with the OMAP remoteproc >> driver publishing itself as having an MMU with the remoteproc core. The >> IOMMU API invoke the appropriate iommu_ops. >> >> You can lookup the functions rproc_enable_iommu()/rproc_disable_iommu() >> in the remoteproc core. The IOMMU enabling sequences happen within the >> iommu_attach_device() API. The call flow is >> iommu_attach_device()->omap_iommu_attach_dev()->omap_iommu_attach()-> >> iommu_enable()-> >>omap_device_deassert_hardreset, pm_runtime_get_sync, omap2_iommu_enable. > > OK. The thing to check here is that you have a separate device driver > for each sysc/syss device registers. This is because each hardware module > can be independently clocked and idled. Otherwise things will break at > some point. And no "things are configured for autoidle" or "we're not > doing PM is not a good excuse here" :) > > Can you please check that? If the remoteproc driver and iommu driver > are tinkering with registers in separate hardware modules, we have > a layering violation. My guess is that we have at least two hardware > modules involved here, one for the iommu and one for the DSP device. Only the IOMMU has a SYSC/SYSS device register. It has both a soft-reset as well as a hard-reset line. The IOMMU stays in reset, and its state machine/programming is controlled through the remoteproc driver. The clock source is also single clock going into the remote processor subsystem, and split up internally to feed the memories and the processors. For the PRCM to auto-gate the clocks, we also need the processor to be executing a IDLE (DSPs) or WFI/WFE (Cortex M3/M4s). Just the IOMMU will allow the OCP idle because of the associated sysc/syss registers. Depending on the remote processor, there might be a separate internal module (like the DSPs usually have a separate SYSC module), but that programming is left to the software running on the DSP. > > Typically we handle these registers by mapping them to the PM runtime > functions for the interconnect so we can reset and idle the hardware > modules even if there is no driver, see for example > omap54xx_mmu_dsp_hwmod. I haven't yet submitted the DRA7xx hwmods, but they will look almost exactly like the OMAP5 ones. The reset and idle on these are in general not effective at boot time since these are also controlled by a hard-reset line, so that's left to the drivers to deal with it through the omap_device_deassert_hardreset API. >>> >>> If the MMU configuration is one time init, it may make sense to add >>> it to the hwmod reset function. However, if the Linux kernel side >>> driver needs to configure things depending on the DSP firmware, it >>> should be done in the kernel side device driver. >> >>
Re: [RFC PATCH 1/4] ARM: OMAP2: DRA7: Modify optimize string comparisons in soc_is calls
On Thursday 03 September 2015 09:45 PM, Tony Lindgren wrote: * Keerthy[150902 03:23]: Currently everytime soc_is calls are made, firstly device tree nodes are parsed and then string comparisons are made to determine the soc version. Optimizing it to be done one time and store the result. Use the stored value in all the subsequent checks for soc_is calls. ... --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -44,12 +44,29 @@ static char soc_name[OMAP_SOC_MAX_NAME_LENGTH]; static char soc_rev[OMAP_SOC_MAX_NAME_LENGTH]; u32 omap_features; +static int soc_ids[MAX_ID]; Hmm why would we need to keep an array of the non-booted socs? We know they're all false after booting.. A bitmask is usually used here? Yes. This will be more optimal. I will implement using a bit mask. 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 -- 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/3][v4] drivers: usb: dwc3: Add frame length adjustment quirk
Add adjust_frame_length_quirk for writing to fladj register which adjusts (micro)frame length to value provided by "snps,quirk-frame-length-adjustment" property thus avoiding USB 2.0 devices to time-out over a longer run Signed-off-by: Nikhil Badola--- Changes for v4: Removed mixed declerations and code drivers/usb/dwc3/core.c | 34 ++ drivers/usb/dwc3/core.h | 5 + drivers/usb/dwc3/platform_data.h | 2 ++ 3 files changed, 41 insertions(+) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 064123e..6270581 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -143,6 +143,32 @@ static int dwc3_soft_reset(struct dwc3 *dwc) return 0; } +/* + * dwc3_frame_length_adjustment - Adjusts frame length if required + * @dwc3: Pointer to our controller context structure + * @fladj: Value of GFLADJ_30MHZ to adjust frame length + */ +static void dwc3_frame_length_adjustment(struct dwc3 *dwc, u32 fladj) +{ + u32 reg; + u32 dft; + + if (dwc->revision < DWC3_REVISION_250A) + return; + + if (fladj == 0) + return; + + reg = dwc3_readl(dwc->regs, DWC3_GFLADJ); + dft = reg & DWC3_GFLADJ_30MHZ_MASK; + if (!dev_WARN_ONCE(dwc->dev, dft == fladj, + "request value same as default, ignoring\n")) { + reg &= ~DWC3_GFLADJ_30MHZ_MASK; + reg |= DWC3_GFLADJ_30MHZ_SDBND_SEL | fladj; + dwc3_writel(dwc->regs, DWC3_GFLADJ, reg); + } +} + /** * dwc3_free_one_event_buffer - Frees one event buffer * @dwc: Pointer to our controller context structure @@ -779,6 +805,7 @@ static int dwc3_probe(struct platform_device *pdev) u8 lpm_nyet_threshold; u8 tx_de_emphasis; u8 hird_threshold; + u32 fladj = 0; int ret; @@ -886,6 +913,9 @@ static int dwc3_probe(struct platform_device *pdev) _de_emphasis); of_property_read_string(node, "snps,hsphy_interface", >hsphy_interface); + of_property_read_u32(node, +"snps,quirk-frame-length-adjustment", +); } else if (pdata) { dwc->maximum_speed = pdata->maximum_speed; dwc->has_lpm_erratum = pdata->has_lpm_erratum; @@ -915,6 +945,7 @@ static int dwc3_probe(struct platform_device *pdev) tx_de_emphasis = pdata->tx_de_emphasis; dwc->hsphy_interface = pdata->hsphy_interface; + fladj = pdata->fladj_value; } /* default to superspeed if no maximum_speed passed */ @@ -971,6 +1002,9 @@ static int dwc3_probe(struct platform_device *pdev) goto err1; } + /* Adjust Frame Length */ + dwc3_frame_length_adjustment(dwc, fladj); + usb_phy_set_suspend(dwc->usb2_phy, 0); usb_phy_set_suspend(dwc->usb3_phy, 0); ret = phy_power_on(dwc->usb2_generic_phy); diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index 0447788..9188745 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -124,6 +124,7 @@ #define DWC3_GEVNTCOUNT(n) (0xc40c + (n * 0x10)) #define DWC3_GHWPARAMS80xc600 +#define DWC3_GFLADJ0xc630 /* Device Registers */ #define DWC3_DCFG 0xc700 @@ -234,6 +235,10 @@ /* Global HWPARAMS6 Register */ #define DWC3_GHWPARAMS6_EN_FPGA(1 << 7) +/* Global Frame Length Adjustment Register */ +#define DWC3_GFLADJ_30MHZ_SDBND_SEL(1 << 7) +#define DWC3_GFLADJ_30MHZ_MASK 0x3f + /* Device Configuration Register */ #define DWC3_DCFG_DEVADDR(addr)((addr) << 3) #define DWC3_DCFG_DEVADDR_MASK DWC3_DCFG_DEVADDR(0x7f) diff --git a/drivers/usb/dwc3/platform_data.h b/drivers/usb/dwc3/platform_data.h index d3614ec..400b197 100644 --- a/drivers/usb/dwc3/platform_data.h +++ b/drivers/usb/dwc3/platform_data.h @@ -46,5 +46,7 @@ struct dwc3_platform_data { unsigned tx_de_emphasis_quirk:1; unsigned tx_de_emphasis:2; + u32 fladj_value; + const char *hsphy_interface; }; -- 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 v2] security: device_cgroup: fix RCU lockdep splat
On Thu, Sep 03, 2015 at 08:48:39AM -0500, Serge E. Hallyn wrote: > On Wed, Sep 02, 2015 at 05:14:33PM -0700, Paul E. McKenney wrote: > > On Wed, Sep 02, 2015 at 12:24:50PM -0400, Tejun Heo wrote: > > > cc'ing Paul. > > > > > > On Wed, Sep 02, 2015 at 08:12:28AM -0500, Felipe Balbi wrote: > > > > while booting AM437x device, the following splat > > > > triggered: > > > > > > > > [ 12.005238] === > > > > [ 12.009749] [ INFO: suspicious RCU usage. ] > > > > [ 12.014116] 4.2.0-next-20150831 #1154 Not tainted > > > > [ 12.019050] --- > > > > [ 12.023408] security/device_cgroup.c:405 device_cgroup:verify_new_ex > > > > called without proper synchronization! > > > ... > > > > [ 12.128326] [] (verify_new_ex) from [] > > > > (devcgroup_access_write+0x374/0x658) > > > > [ 12.137426] [] (devcgroup_access_write) from [] > > > > (cgroup_file_write+0x28/0x1bc) > > > > [ 12.146796] [] (cgroup_file_write) from [] > > > > (kernfs_fop_write+0xc0/0x1b8) > > > > [ 12.155620] [] (kernfs_fop_write) from [] > > > > (__vfs_write+0x1c/0xd8) > > > > [ 12.163783] [] (__vfs_write) from [] > > > > (vfs_write+0x90/0x16c) > > > > [ 12.171426] [] (vfs_write) from [] > > > > (SyS_write+0x44/0x9c) > > > > [ 12.178806] [] (SyS_write) from [] > > > > (ret_fast_syscall+0x0/0x1c) > > > > > > This shouldn't be happening because devcgroup_access_write() always > > > grabs devcgroup_mutex. Looking at the log, the culprit seems to be > > > f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to > > > RCU_LOCKDEP_WARN()"). It missed the bang for the second test while > > > inverting it, so adding rcu_read_lock() isn't the right fix here. > > > > > > Paul, can you please fix it? > > > > Gah! Please see below. > > > > Thanx, Paul > > > > > > > > security/device_cgroup: Fix RCU_LOCKDEP_WARN() condition > > > > f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()") > > introduced a bug by incorrectly inverting the condition when moving from > > rcu_lockdep_assert() to RCU_LOCKDEP_WARN(). This commit therefore fixes > > the inversion. > > > > Reported-by: Felipe Balbi> > Reported-by: Tejun Heo > > Signed-off-by: Paul E. McKenney > > Cc: Serge Hallyn > > Oh, makes sense :) (didn't see the original patch when it came by, sorry) I should have CCed you, apologies for failing to do so. > Acked-by: Serge Hallyn Added, thank you! Thanx, Paul > > diff --git a/security/device_cgroup.c b/security/device_cgroup.c > > index 73455089feef..03c1652c9a1f 100644 > > --- a/security/device_cgroup.c > > +++ b/security/device_cgroup.c > > @@ -401,7 +401,7 @@ static bool verify_new_ex(struct dev_cgroup *dev_cgroup, > > bool match = false; > > > > RCU_LOCKDEP_WARN(!rcu_read_lock_held() && > > -lockdep_is_held(_mutex), > > +!lockdep_is_held(_mutex), > > "device_cgroup:verify_new_ex called without proper > > synchronization"); > > > > if (dev_cgroup->behavior == DEVCG_DEFAULT_ALLOW) { > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/9] usb: dwc3: core: Adapt to named interrupts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/15 17:34, Felipe Balbi wrote: > On Wed, Sep 02, 2015 at 05:24:19PM +0300, Roger Quadros wrote: >> From: Felipe Balbi>> >> Add support to use interrupt names, >> >> Following are the interrupt names >> >> Peripheral Interrupt - peripheral >> HOST Interrupt - host >> OTG Interrupt - otg >> >> [Roger Q] >> - If any of these are missing we use the >> first available IRQ resource so that we don't >> break with older DTBs. > > this is what original commit did: > > commit ecd5f71cfd663bcd4efd2f29824acd8b2ba9715d > Author: Felipe Balbi > Date: Fri Jan 3 13:49:38 2014 -0600 > > usb: dwc3: cleanup IRQ resources > > In order to make it easier for the driver to > figure out which modes of operation it has, > and because some dwc3 integrations have rather > fuzzy IRQ routing, we now require three different > IRQ numbers (peripheral, host, otg). > > In order to do that and maintain backwards compatibility, > we still maintain support for the old IRQ resource name, > but if you *really* want to have proper peripheral/host/otg > support, you should make sure your resources are correct. > > Signed-off-by: Felipe Balbi This is better since we request the resource only if needed and bail out if it is not present. > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c > index 60580a01cdd2..1f01031873b7 100644 > --- a/drivers/usb/dwc3/core.c > +++ b/drivers/usb/dwc3/core.c > @@ -556,10 +556,22 @@ static int dwc3_core_get_phy(struct dwc3 *dwc) > static int dwc3_core_init_mode(struct dwc3 *dwc) > { > struct device *dev = dwc->dev; > + struct platform_device *pdev = to_platform_device(dev); > int ret; > > switch (dwc->dr_mode) { > case USB_DR_MODE_PERIPHERAL: > + dwc->gadget_irq = platform_get_irq_byname(pdev, > "dwc3_peripheral"); Shall we just name it just "peripheral"? > + if (dwc->gadget_irq < 0) { > + dwc->gadget_irq = platform_get_irq_byname(pdev, > "dwc_usb3"); How will this work? Currently we don't have a name for the IRQ in the DT. > + if (dwc->gadget_irq < 0) { > + dev_err(dev, "missing IRQ\n"); > + return dwc->gadget_irq; > + } else { > + dev_warn(dev, "dwc_usb3 resource is > deprecated\n"); Do we want to warn about legacy nodes? > + } > + } > + > dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE); > ret = dwc3_gadget_init(dwc); > if (ret) { > @@ -568,6 +580,22 @@ static int dwc3_core_init_mode(struct dwc3 *dwc) > } > break; > case USB_DR_MODE_HOST: > + dwc->xhci_irq = platform_get_irq_byname(pdev, "dwc3_host"); > + if (dwc->xhci_irq < 0) { > + dwc->xhci_irq = platform_get_irq_byname(pdev, > "dwc_usb3"); > + if (dwc->xhci_irq < 0) { > + dev_err(dev, "missing Host IRQ\n"); > + return dwc->xhci_irq; > + } else { > + dev_warn(dev, "dwc_usb3 resource is > deprecated\n"); > + } > + > + dwc->xhci_resources[1].start = dwc->xhci_irq; > + dwc->xhci_resources[1].end = dwc->xhci_irq; > + dwc->xhci_resources[1].flags = IORESOURCE_IRQ; > + dwc->xhci_resources[1].name = "xhci"; > + } > + > dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST); > ret = dwc3_host_init(dwc); > if (ret) { > @@ -576,6 +604,28 @@ static int dwc3_core_init_mode(struct dwc3 *dwc) > } > break; > case USB_DR_MODE_OTG: > + dwc->gadget_irq = platform_get_irq_byname(pdev, > "dwc3_peripheral"); > + if (dwc->gadget_irq < 0) { > + dwc->gadget_irq = platform_get_irq_byname(pdev, > "dwc_usb3"); > + if (dwc->gadget_irq < 0) { > + dev_err(dev, "missing IRQ\n"); > + return dwc->gadget_irq; > + } else { > + dev_warn(dev, "dwc_usb3 resource is > deprecated\n"); > + } > + > + dwc->xhci_irq = dwc->gadget_irq; > + dwc->otg_irq = dwc->gadget_irq; > + } else { > + dwc->xhci_irq = platform_get_irq_byname(pdev, > "dwc3_host"); > + if (dwc->xhci_irq < 0) { > + dev_err(dev, "missing Host IRQ\n"); > + return dwc->xhci_irq; > + } > + > + dwc->otg_irq = platform_get_irq_byname(pdev, >
Re: [PATCH v2] security: device_cgroup: fix RCU lockdep splat
On Thu, Sep 03, 2015 at 09:56:05AM -0400, Josh Boyer wrote: > On Wed, Sep 2, 2015 at 8:14 PM, Paul E. McKenney >wrote: > > On Wed, Sep 02, 2015 at 12:24:50PM -0400, Tejun Heo wrote: > >> cc'ing Paul. > >> > >> On Wed, Sep 02, 2015 at 08:12:28AM -0500, Felipe Balbi wrote: > >> > while booting AM437x device, the following splat > >> > triggered: > >> > > >> > [ 12.005238] === > >> > [ 12.009749] [ INFO: suspicious RCU usage. ] > >> > [ 12.014116] 4.2.0-next-20150831 #1154 Not tainted > >> > [ 12.019050] --- > >> > [ 12.023408] security/device_cgroup.c:405 device_cgroup:verify_new_ex > >> > called without proper synchronization! > >> ... > >> > [ 12.128326] [] (verify_new_ex) from [] > >> > (devcgroup_access_write+0x374/0x658) > >> > [ 12.137426] [] (devcgroup_access_write) from [] > >> > (cgroup_file_write+0x28/0x1bc) > >> > [ 12.146796] [] (cgroup_file_write) from [] > >> > (kernfs_fop_write+0xc0/0x1b8) > >> > [ 12.155620] [] (kernfs_fop_write) from [] > >> > (__vfs_write+0x1c/0xd8) > >> > [ 12.163783] [] (__vfs_write) from [] > >> > (vfs_write+0x90/0x16c) > >> > [ 12.171426] [] (vfs_write) from [] > >> > (SyS_write+0x44/0x9c) > >> > [ 12.178806] [] (SyS_write) from [] > >> > (ret_fast_syscall+0x0/0x1c) > >> > >> This shouldn't be happening because devcgroup_access_write() always > >> grabs devcgroup_mutex. Looking at the log, the culprit seems to be > >> f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to > >> RCU_LOCKDEP_WARN()"). It missed the bang for the second test while > >> inverting it, so adding rcu_read_lock() isn't the right fix here. > >> > >> Paul, can you please fix it? > > > > Gah! Please see below. > > > > Thanx, Paul > > > > > > > > security/device_cgroup: Fix RCU_LOCKDEP_WARN() condition > > > > f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()") > > introduced a bug by incorrectly inverting the condition when moving from > > rcu_lockdep_assert() to RCU_LOCKDEP_WARN(). This commit therefore fixes > > the inversion. > > > > Reported-by: Felipe Balbi > > Reported-by: Tejun Heo > > Signed-off-by: Paul E. McKenney > > Cc: Serge Hallyn > > Just tested this patch without Felipe's previous version on all my > machines. The splat is indeed gone. > > Tested-by: Josh Boyer Thank you, added! Thanx, Paul > josh > > > > > diff --git a/security/device_cgroup.c b/security/device_cgroup.c > > index 73455089feef..03c1652c9a1f 100644 > > --- a/security/device_cgroup.c > > +++ b/security/device_cgroup.c > > @@ -401,7 +401,7 @@ static bool verify_new_ex(struct dev_cgroup *dev_cgroup, > > bool match = false; > > > > RCU_LOCKDEP_WARN(!rcu_read_lock_held() && > > -lockdep_is_held(_mutex), > > +!lockdep_is_held(_mutex), > > "device_cgroup:verify_new_ex called without proper > > synchronization"); > > > > if (dev_cgroup->behavior == DEVCG_DEFAULT_ALLOW) { > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > -- 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