Re: [PATCH] dmaengine: pl330: Fix race in residue reporting
On Sat, 2015-11-07 at 21:40 +0900, Krzysztof Kozlowski wrote:
> W dniu 06.11.2015 o 20:11, Sjoerd Simons pisze:
> > When a transfer completes there is a small window between the
> > descriptor
> > being unset as the current active one in the thread and it being
> > marked
> > as done. This causes the residue to be incorrectly set when
> > pl330_tx_status is run in that window. Practically this caused
> > issue for me with audio playback as the residue goes up during a
> > transfer (as the in-progress transfer is no longer accounted for),
> > which makes the higher levels think the audio ringbuffer wrapped
> > around
> > and thus did a sudden big jump forward.
> >
> > To resolve this, add a field protected by the dma engine lock to
> > indicate the transfer is done but the status hasn't been updated
> > yet.
> >
> > Also fix the locking in pl330_tx_status, as the function inspects
> > the
> > threads req_running field and queries the dma engine for the
> > current
> > state of the running transfer the dma engine lock needs to be held
> > to
> > ensure the active descriptor doesn't change underneath it.
> >
> > Signed-off-by: Sjoerd Simons <sjoerd.sim...@collabora.co.uk>
> >
> > ---
> >
> > drivers/dma/pl330.c | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> > index 17ee758..6c8243b 100644
> > --- a/drivers/dma/pl330.c
> > +++ b/drivers/dma/pl330.c
> > @@ -503,6 +503,8 @@ struct dma_pl330_desc {
> > struct pl330_reqcfg rqcfg;
> >
> > enum desc_status status;
> > + /* Transfer completed, but not yet moved to DONE state */
> > + bool xferred;
> >
> > int bytes_requested;
> > bool last;
> > @@ -1463,6 +1465,9 @@ static void dma_pl330_rqcb(struct
> > dma_pl330_desc *desc, enum pl330_op_err err)
> > spin_lock_irqsave(>lock, flags);
> >
> > desc->status = DONE;
> > + spin_lock(>thread->dmac->lock);
> > + desc->xferred = false;
> > + spin_unlock(>thread->dmac->lock);
> >
> > spin_unlock_irqrestore(>lock, flags);
> >
> > @@ -1595,6 +1600,7 @@ static int pl330_update(struct pl330_dmac
> > *pl330)
> >
> > /* Detach the req */
> > descdone = thrd->req[active].desc;
> > + descdone->xferred = true;
> > thrd->req[active].desc = NULL;
>
> Looking at the code indeed the small window could happen. How can I
> reproduce it? Can you describe your system?
I'm using a Rock 2 square (RK3288 based) board, running Debian Jessie
and simply playing back audio using vlc & pulseaudio.
For some reason when using vlc, pulseaudio is polling the hw pointer
position very very often and seems to hit this tiny window a few times
a minute depending a bit on system load. This causes some audiable
issues and eventually underflowing (as vlc fills the pulseaudio buffer
at a constant rate, but due to this, pulse pushes the data faster then
the actual playback rate every so often).
> As for the change itself, how about adding a new value to
> desc_status?
> Now you are actually introducing a semi-status field.
The reason i picked this way this was was due to the current locking
scheme. The locking order is channel, then controller (when locking
both). While processing the events (and update the active descriptor),
the controller is locked so the status can't be directly updated (as
that's protected by the channel lock). And we can't grab the channel
lock without dopping the controller one first :).
Keeping one status field might well be possible, but would require at
least reworking the locking here.
> Best regards,
> Krzysztof
>
> >
> > thrd->req_running = -1;
> > @@ -2250,13 +2256,14 @@ pl330_tx_status(struct dma_chan *chan,
> > dma_cookie_t cookie,
> > goto out;
> >
> > spin_lock_irqsave(>lock, flags);
> > + spin_lock(>thread->dmac->lock);
> >
> > if (pch->thread->req_running != -1)
> > running = pch->thread->req[pch->thread-
> > >req_running].desc;
> >
> > /* Check in pending list */
> > list_for_each_entry(desc, >work_list, node) {
> > - if (desc->status == DONE)
> > + if (desc->xferred || desc->status == DONE)
> > transferred = desc->bytes_requested;
> > else if (running && desc == running)
> > transferred =
> > @@ -2281,6 +2288,7 @@ pl330_tx_status(struct dma_chan *chan,
> > dma_cookie_t cookie,
> > if (desc->last)
> > residual = 0;
> > }
> > + spin_unlock(>thread->dmac->lock);
> > spin_unlock_irqrestore(>lock, flags);
> >
> > out:
> >
>
--
Sjoerd Simons
Collabora Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dmaengine: pl330: Fix race in residue reporting
When a transfer completes there is a small window between the descriptor
being unset as the current active one in the thread and it being marked
as done. This causes the residue to be incorrectly set when
pl330_tx_status is run in that window. Practically this caused
issue for me with audio playback as the residue goes up during a
transfer (as the in-progress transfer is no longer accounted for),
which makes the higher levels think the audio ringbuffer wrapped around
and thus did a sudden big jump forward.
To resolve this, add a field protected by the dma engine lock to
indicate the transfer is done but the status hasn't been updated yet.
Also fix the locking in pl330_tx_status, as the function inspects the
threads req_running field and queries the dma engine for the current
state of the running transfer the dma engine lock needs to be held to
ensure the active descriptor doesn't change underneath it.
Signed-off-by: Sjoerd Simons <sjoerd.sim...@collabora.co.uk>
---
drivers/dma/pl330.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 17ee758..6c8243b 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -503,6 +503,8 @@ struct dma_pl330_desc {
struct pl330_reqcfg rqcfg;
enum desc_status status;
+ /* Transfer completed, but not yet moved to DONE state */
+ bool xferred;
int bytes_requested;
bool last;
@@ -1463,6 +1465,9 @@ static void dma_pl330_rqcb(struct dma_pl330_desc *desc,
enum pl330_op_err err)
spin_lock_irqsave(>lock, flags);
desc->status = DONE;
+ spin_lock(>thread->dmac->lock);
+ desc->xferred = false;
+ spin_unlock(>thread->dmac->lock);
spin_unlock_irqrestore(>lock, flags);
@@ -1595,6 +1600,7 @@ static int pl330_update(struct pl330_dmac *pl330)
/* Detach the req */
descdone = thrd->req[active].desc;
+ descdone->xferred = true;
thrd->req[active].desc = NULL;
thrd->req_running = -1;
@@ -2250,13 +2256,14 @@ pl330_tx_status(struct dma_chan *chan, dma_cookie_t
cookie,
goto out;
spin_lock_irqsave(>lock, flags);
+ spin_lock(>thread->dmac->lock);
if (pch->thread->req_running != -1)
running = pch->thread->req[pch->thread->req_running].desc;
/* Check in pending list */
list_for_each_entry(desc, >work_list, node) {
- if (desc->status == DONE)
+ if (desc->xferred || desc->status == DONE)
transferred = desc->bytes_requested;
else if (running && desc == running)
transferred =
@@ -2281,6 +2288,7 @@ pl330_tx_status(struct dma_chan *chan, dma_cookie_t
cookie,
if (desc->last)
residual = 0;
}
+ spin_unlock(>thread->dmac->lock);
spin_unlock_irqrestore(>lock, flags);
out:
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4
On Thu, 2015-10-08 at 16:41 +0200, Arnd Bergmann wrote: > On Thursday 08 October 2015 11:27:13 Sjoerd Simons wrote: > > On Thu, 2015-10-08 at 10:37 +0200, Arnd Bergmann wrote: > > > On Thursday 08 October 2015 16:46:27 Krzysztof Kozlowski wrote: > > > > On 08.10.2015 16:41, Arnd Bergmann wrote: > > > > > On Thursday 08 October 2015 03:48:36 Anand Moon wrote: > > > > > > diff --git a/arch/arm/configs/exynos_defconfig > > > > > > b/arch/arm/configs/exynos_defconfig > > > > > > index 1ff2bfa..5d1937b 100644 > > > > > > --- a/arch/arm/configs/exynos_defconfig > > > > > > +++ b/arch/arm/configs/exynos_defconfig > > > > > > @@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y > > > > > > CONFIG_DM_CRYPT=m > > > > > > CONFIG_NETDEVICES=y > > > > > > CONFIG_SMSC911X=y > > > > > > +CONFIG_USB_RTL8152=y > > > > > > CONFIG_USB_USBNET=y > > > > > > CONFIG_USB_NET_SMSC75XX=y > > > > > > CONFIG_USB_NET_SMSC95XX=y > > > > > > > > > > Can we make that a loadable module for multi_v7_defconfig? > > > > > > > > What about nfsroot boots? We were discussing this also here: > > > > http://linux-arm-kernel.infradead.narkive.com/lG5g4hrB/patch-ar > > > > m-mu > > > > lti-v7-defconfig-enable-usb3503 > > > > > > > > and actually I would be happy to see a confirmed policy about > > > > that. > > > > Everything should be a module for multi_v7? > > > > > > We try to make as much as possible modular here, and NFS root is > > > a > > > corner > > > case: it's possible to do NFS root with an initramfs, but it's > > > easier > > > not > > > to. Is it something you do a lot on this hardware? > > > > It's a workflow thing though, not a hardware specific thing. I > > personally tend to use NFS root quite often and so do various > > colleagues irrespective of the hardware (and an XU4 is bound to > > appear > > on my desk someday). > > > > Now I personally really don't mind whether NFS root requires a > > ramdisk > > or not (though some consistency would be nice). However deciding it > > on > > a per device basis just makes everything quite fuzzy (e.g. my > > recent > > rockchip multi_v7 patchset first ended up in a similar discussion, > > though v2 was merged without further comments when I indicated in > > the > > cover letter that i used the NFS root use-case as one of the > > deciding > > factors for y vs. m). > > > > It would be really good to see someone put their foot down on the > > general policy (e.g. the arm-soc maintainers?), such that this > > discussion doesn't need to happen every time > > Yes, agreed, that what I'm trying to do here ;-) I see, sorry I misunderstood what you were after. > I realize that building things as modules is a hassle, it is so for > some things more than for others, so I keep asking the question > to everyone to find out what a good balance is to make as much as > possible modules without hurting too much. Fwiw, I don't find building modules overly cumbersome. Getting an initramfs capable of moving on to an NFS root is mostly a one-time thing (not unlike setting up the nfs root itself) and injecting modules into it is relatively simple (doubly so if taking advantage of the multiple cpio archive feature linux has). Interestingly, for me not building things as modules in multi_v7 tends to cause more work as it hides a few categories of bugs that tend to crop up once building distro kernels (e.g. missing module aliases, missing module device table entries, implicitly relying on clocks being active during probe as unused clocks only get turned of late in the init sequence etc). > Once we have a firm policy in place, we should probably change all > the existing symbols. ++ -- Sjoerd Simons Collabora Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4
On Thu, 2015-10-08 at 10:37 +0200, Arnd Bergmann wrote: > On Thursday 08 October 2015 16:46:27 Krzysztof Kozlowski wrote: > > On 08.10.2015 16:41, Arnd Bergmann wrote: > > > On Thursday 08 October 2015 03:48:36 Anand Moon wrote: > > > > diff --git a/arch/arm/configs/exynos_defconfig > > > > b/arch/arm/configs/exynos_defconfig > > > > index 1ff2bfa..5d1937b 100644 > > > > --- a/arch/arm/configs/exynos_defconfig > > > > +++ b/arch/arm/configs/exynos_defconfig > > > > @@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y > > > > CONFIG_DM_CRYPT=m > > > > CONFIG_NETDEVICES=y > > > > CONFIG_SMSC911X=y > > > > +CONFIG_USB_RTL8152=y > > > > CONFIG_USB_USBNET=y > > > > CONFIG_USB_NET_SMSC75XX=y > > > > CONFIG_USB_NET_SMSC95XX=y > > > > > > Can we make that a loadable module for multi_v7_defconfig? > > > > What about nfsroot boots? We were discussing this also here: > > http://linux-arm-kernel.infradead.narkive.com/lG5g4hrB/patch-arm-mu > > lti-v7-defconfig-enable-usb3503 > > > > and actually I would be happy to see a confirmed policy about that. > > Everything should be a module for multi_v7? > > We try to make as much as possible modular here, and NFS root is a > corner > case: it's possible to do NFS root with an initramfs, but it's easier > not > to. Is it something you do a lot on this hardware? It's a workflow thing though, not a hardware specific thing. I personally tend to use NFS root quite often and so do various colleagues irrespective of the hardware (and an XU4 is bound to appear on my desk someday). Now I personally really don't mind whether NFS root requires a ramdisk or not (though some consistency would be nice). However deciding it on a per device basis just makes everything quite fuzzy (e.g. my recent rockchip multi_v7 patchset first ended up in a similar discussion, though v2 was merged without further comments when I indicated in the cover letter that i used the NFS root use-case as one of the deciding factors for y vs. m). It would be really good to see someone put their foot down on the general policy (e.g. the arm-soc maintainers?), such that this discussion doesn't need to happen every time :) -- Sjoerd Simons Collabora Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 usb3503
On Tue, 2015-09-15 at 15:50 +0900, Krzysztof Kozlowski wrote: > 2015-09-14 17:35 GMT+09:00 Riku Voipio <riku.voi...@linaro.org>: > > On 5 June 2015 at 15:45, Arnd Bergmann <a...@arndb.de> wrote: > > > On Thursday 04 June 2015 10:47:07 Kevin Hilman wrote: > > > > > > > > > But I wonder why is not working, shouldn't the driver defer > > > > > and > > > > > be probed again once the PHY driver probe succeeds? > > > > > > > > Yeah, I'm not sure why that isn't working, and didn't look into > > > > it. > > > > > > > > FWIW, the same problem happens when both are modules. If you > > > > modprobe > > > > usb3503 first, then the phy, it doesn't work. You have to load > > > > the phy > > > > before the usb3503. > > > > > The driver does not try to get a reference to the phy, and it > > > does > > > not return -EPROBE_DEFER in any circumstance, so I assume it just > > > runs into an error condition on the first probe and does not > > > try again. > > > > > I don't really understand why the driver registers both an > > > i2c_driver > > > and a platform_driver, or if that is required, but it may also > > > complicate getting deferred probing to work here. > > > > Is someone looking into fixing it? > > Fixing what? The PHY issue? The driver not supporting deferred probe? > > As for module vs builtin, this is somehow orthogonal for me. > Although modules are preferred on multi_v7 but in case of > boot-essential drivers this should not be a requirement. I also don't > use initrd for network boot... however my root is on MMC. Regardless > if of that I would expect nfsroot to be working on multi_v7 kernel. When posting a set of multi_v7 config changes recently to improve how we support RockChip, Thierry argued the case for building things as modules as much as possible (even if that means needing an initramfs to complete boot)[0].. You're arguing the exact oposite here, while I can see the points in both arguments (though i'm leaning to agreeing with Thierry) it would be nice to work out a common policy here as multi_v7 seems to be a rather big mismatch currently. Fwiw, looking at the arm64 defconfig it currently has everything built in. Which isn't too bad as there aren't that many arm64 boards in mainline yet, but I bet it's going to run into similar issues at some point. 0: http://lists.infradead.org/pipermail/linux-rockchip/2015-September/0 04280.html > From my point of view this is the same case as USB_NET_SMSC75XX or > USB_NET_SMSC95XX, so: > 1. Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com> > 2. +1 for CONFIG_PHY_SAMSUNG_USB2=y (regardless of fixing issues in > the driver) > 3. +1 for fixing the PHY driver > > > Best regards, > Krzysztof > -- > To unsubscribe from this list: send the line "unsubscribe linux > -samsung-soc" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sjoerd Simons <sjoerd.sim...@collabora.co.uk> Collabora Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: exynos_defconfig: Enable big.LITTLE CPUidle support
On Fri, 2015-08-28 at 10:16 +0200, Javier Martinez Canillas wrote:
Some Exynos big.LITTLE boards (i.e: Exynos5420 and Exynos5800 based
Chromebooks) have proper firmware that allow the big.LITTLE CPUidle
driver to work correctly, so enable support for this.
Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com
---
Kukjin and Krzysztof,
As you know there are other boards like the Exynos5422 based Odroid
XU{3,4}
whose firmware is broken due leaving CCI in secure mode which means
that the
kernel MCPM support can't properly manage CCI.
So if you pick this patch, it should be tested in kernelci before
appearing
in linux-next to prevent any boot issues.
I've pushed this patch into Collabora's for-next branch, which should
get picked up by kernelci soonish.
--
Sjoerd Simons
Collabora Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ARM: EXYNOS: reset KFC cores when cpu is up
On Wed, 2015-07-15 at 10:36 +0900, Chanho Park wrote:
The cpu booting of exynos5422 has been still broken since we
discussed
it in last year[1]. I found this resetting codes from odroid-xu3
kernel of
hardkernel, it could help to boot 8 cores well. This patch need to
have
more test like STR and other SoC especially exynos5800 which is
variant
of exynos5422. If this patch is broken on exynos5800, I'll find
another
way to check exynos5422.
This patch is top of my previous exynos5422 cpu ordering patch[2] and
need to enable CONFIG_EXYNOS5420_MCPM=y
[0.047509] CPU0: update cpu_capacity 448
[0.047534] CPU0: thread -1, cpu 0, socket 1, mpidr 8100
[0.047874] Setting up static identity map for 0x400082c0 -
0x40008318
[0.048340] ARM CCI driver probed
[0.048597] Exynos MCPM support installed
[0.065676] CPU1: update cpu_capacity 448
[0.065685] CPU1: thread -1, cpu 1, socket 1, mpidr 8101
[0.070672] CPU2: update cpu_capacity 448
[0.070680] CPU2: thread -1, cpu 2, socket 1, mpidr 8102
[0.075644] CPU3: update cpu_capacity 448
[0.075653] CPU3: thread -1, cpu 3, socket 1, mpidr 8103
[0.080590] CPU4: update cpu_capacity 1535
[0.080600] CPU4: thread -1, cpu 0, socket 0, mpidr 8000
[0.085591] CPU5: update cpu_capacity 1535
[0.085599] CPU5: thread -1, cpu 1, socket 0, mpidr 8001
[0.090590] CPU6: update cpu_capacity 1535
[0.090598] CPU6: thread -1, cpu 2, socket 0, mpidr 8002
[0.095585] CPU7: update cpu_capacity 1535
[0.095593] CPU7: thread -1, cpu 3, socket 0, mpidr 8003
[0.095720] Brought up 8 CPUs
[1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015
-June/350632.html
[2]:https://patchwork.kernel.org/patch/6782891/
Cc: Joonyoung Shim jy0922.s...@samsung.com
Cc: Chanwoo Choi cw00.c...@samsung.com
Cc: Kevin Hilman khil...@kernel.org
Cc: Heesub Shin heesub.s...@samsung.com
Cc: Mauro Ribeiro mauro.ribe...@hardkernel.com
Cc: Abhilash Kesavan a.kesa...@samsung.com
Cc: Przemyslaw Marczak p.marc...@samsung.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
Signed-off-by: Chanho Park parkc...@gmail.com
---
arch/arm/mach-exynos/mcpm-exynos.c | 13 -
arch/arm/mach-exynos/regs-pmu.h| 6 ++
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach
-exynos/mcpm-exynos.c
index 9bdf547..a076dde 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -70,7 +70,18 @@ static int exynos_cpu_powerup(unsigned int cpu,
unsigned int cluster)
cluster = EXYNOS5420_NR_CLUSTERS)
return -EINVAL;
- exynos_cpu_power_up(cpunr);
+ if (!exynos_cpu_power_state(cpunr)) {
+ exynos_cpu_power_up(cpunr);
+
+ if (soc_is_exynos5800() cluster) {
This seems a tad subtle. You're assuming here cluster 1 is the little
cluster. Would be good to make this more specific/obvious.
From looking at other mcpm-exynos code the assumption seems valid
(otherwise more code would be broken), so it may make sense to simply
define LITTLE_CLUSTER and BIG_CLUSTER and check explicitely for that.
Krzysztof on IRC mention that the cluster layout is read from MPIDR so
in principle this assumption could be invalidated on some Exynos
versions, but then again, given the amount of fallout from that i don't
see it as a practical issue at the moment :)
+ while (!pmu_raw_readl(S5P_PMU_SPARE2))
+ udelay(10);
Would love to see some documentation for this magical pmu register, but
i guess you can't have them all :)
--
Sjoerd Simons sjoerd.sim...@collabora.co.uk
Collabora Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pwm: Add clk enable/disable for pwm_samsung_enable/pwm_samsung_disable
On Wed, 2015-04-15 at 03:35 +0930, Anand Moon wrote: diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c index 3e9b583..b579753 100644 --- a/drivers/pwm/pwm-samsung.c +++ b/drivers/pwm/pwm-samsung.c @@ -247,6 +247,7 @@ static int pwm_samsung_enable(struct pwm_chip *chip, struct pwm_device *pwm) tcon = ~TCON_MANUALUPDATE(tcon_chan); tcon |= TCON_START(tcon_chan) | TCON_AUTORELOAD(tcon_chan); writel(tcon, our_chip-base + REG_TCON); + clk_prepare_enable(our_chip-base_clk); spin_unlock_irqrestore(samsung_pwm_lock, flags); @@ -265,6 +266,7 @@ static void pwm_samsung_disable(struct pwm_chip *chip, struct pwm_device *pwm) tcon = readl(our_chip-base + REG_TCON); tcon = ~TCON_AUTORELOAD(tcon_chan); writel(tcon, our_chip-base + REG_TCON); + clk_disable_unprepare(our_chip-base_clk); spin_unlock_irqrestore(samsung_pwm_lock, flags); } As far as i can tell this code doesn't have any effect. clk_enable is refcounted, so the clock will stay enabled for as long as the driver is loaded (as it's enabled in _probe). Your code above just raises and lowers the clocks enabled refcount, but won't actually ever cause it to be disabled. With respect to trying to disabling the clocks on pwm_disable, that will need some more work to ensure the output signal has the expected level when you turn of the clock. Specifically, when disabling from a non-100% duty state the driver relies on the PWM turning the output signal low at the end of a duty cycle. However if you turn off the clock at the start of a duty cycle while the output signal is still high it will unexpectedly remain high. -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] pwm: samsung: Fix output race on disabling
On Wed, 2015-04-08 at 10:28 +0200, Lukasz Majewski wrote: Hi Anand, From: Sjoerd Simons sjoerd.sim...@collabora.co.uk When disabling the samsung PWM the output state remains at the level it was in the end of a pwm cycle. In other words, calling pwm_disable when at 100% duty will keep the output active, while at all other setting the output will go/stay inactive. On top of that the samsung PWM settings are double-buffered, which means the new settings only get applied at the start of a new PWM cycle. This patch is already in the linux-pwm for-next tree so should probably be dropped form this patchset to prevent conflicts. -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 Resend] pwm: samsung: Fix output race on disabling
On Wed, 2015-03-18 at 09:08 +0100, Lukasz Majewski wrote:
Hi Sjoerd,
Hey Jingoo, Kukjijn, Lukasz,
Pinging on this one again, could you please review this patch so it
can be merged through the PWM tree?
As fair as I remember, I've already acked the patch :-)
I don't think you did, but i might have missed it ofcourse. Seems
patchwork also missed it though:
https://patchwork.ozlabs.org/patch/446643/
Mind redoing you're acked-by so it gets picked up by patchwork ? :)
On Thu, 2015-03-05 at 09:14 +0100, Sjoerd Simons wrote:
When disabling the samsung PWM the output state remains at the
level it was in the end of a pwm cycle. In other words, calling
pwm_disable when at 100% duty will keep the output active, while at
all other setting the output will go/stay inactive. On top of that
the samsung PWM settings are double-buffered, which means the new
settings only get applied at the start of a new PWM cycle.
This results in a race if the PWM is at 100% duty and a driver
calls: pwm_config (pwm, 0, period);
pwm_disable (pwm);
In this case the PWMs output will unexpectedly stay active, unless
a new PWM cycle happened to start between the register writes in
_config and _disable. As far as i can tell this is a regression
introduced by 3bdf878, before that a call to pwm_config would call
pwm_samsung_enable which, while heavy-handed, made sure the
expected settings were live.
To resolve this, while not re-introducing the issues 3bdf878
(flickering as the PWM got reset while in a PWM cycle). Only force
an update of the settings when at 100% duty, which shouldn't have a
noticeable effect on the output but is enough to ensure the
behaviour is as expected on disable.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
Changes since v1:
Fix small issues pointed out by Tomasz Figa
- Correct various coding style issues
- Read the current value of the tcmp register for comparison
rather then using a non-trivial comparison to decide whether the
current state was 100% duty
- Move the code to force manual update out into its own function
- Clarify the comment indicating why a manual update is sometimes
required
drivers/pwm/pwm-samsung.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index 3e9b583..649f6c4 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -269,12 +269,31 @@ static void pwm_samsung_disable(struct
pwm_chip *chip, struct pwm_device *pwm)
spin_unlock_irqrestore(samsung_pwm_lock, flags); }
+static void pwm_samsung_manual_update(struct samsung_pwm_chip
*chip,
+ struct pwm_device *pwm)
+{
+ unsigned int tcon_chan = to_tcon_channel(pwm-hwpwm);
+ u32 tcon;
+ unsigned long flags;
+
+ spin_lock_irqsave(samsung_pwm_lock, flags);
+
+ tcon = readl(chip-base + REG_TCON);
+ tcon |= TCON_MANUALUPDATE(tcon_chan);
+ writel(tcon, chip-base + REG_TCON);
+
+ tcon = ~TCON_MANUALUPDATE(tcon_chan);
+ writel(tcon, chip-base + REG_TCON);
+
+ spin_unlock_irqrestore(samsung_pwm_lock, flags);
+}
+
static int pwm_samsung_config(struct pwm_chip *chip, struct
pwm_device *pwm, int duty_ns, int period_ns)
{
struct samsung_pwm_chip *our_chip =
to_samsung_pwm_chip(chip); struct samsung_pwm_channel *chan =
pwm_get_chip_data(pwm);
- u32 tin_ns = chan-tin_ns, tcnt, tcmp;
+ u32 tin_ns = chan-tin_ns, tcnt, tcmp, oldtcmp;
/*
* We currently avoid using 64bit arithmetic by using the
@@ -288,6 +307,7 @@ static int pwm_samsung_config(struct pwm_chip
*chip, struct pwm_device *pwm, return 0;
tcnt = readl(our_chip-base + REG_TCNTB(pwm-hwpwm));
+ oldtcmp = readl(our_chip-base + REG_TCMPB(pwm-hwpwm));
/* We need tick count for calculation, not last tick. */
++tcnt;
@@ -335,6 +355,15 @@ static int pwm_samsung_config(struct pwm_chip
*chip, struct pwm_device *pwm, writel(tcnt, our_chip-base +
REG_TCNTB(pwm-hwpwm)); writel(tcmp, our_chip-base +
REG_TCMPB(pwm-hwpwm));
+ /* In case the PWM is currently at 100% duty, force a
manual update
+ * to prevent the signal staying high in the pwm is
disabled shortly
+ * afer this update (before it autoreloaded the new
values) .
+ */
+ if (oldtcmp == (u32) -1) {
+ dev_dbg(our_chip-chip.dev, Forcing manual
update);
+ pwm_samsung_manual_update(our_chip, pwm);
+ }
+
chan-period_ns = period_ns;
chan-tin_ns = tin_ns;
chan-duty_ns = duty_ns;
--
Sjoerd Simons sjoerd.sim...@collabora.co.uk
Collabora Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info
Re: [PATCH v2 Resend] pwm: samsung: Fix output race on disabling
Hey Jingoo, Kukjijn, Lukasz,
Pinging on this one again, could you please review this patch so it can
be merged through the PWM tree?
On Thu, 2015-03-05 at 09:14 +0100, Sjoerd Simons wrote:
When disabling the samsung PWM the output state remains at the level it
was in the end of a pwm cycle. In other words, calling pwm_disable when
at 100% duty will keep the output active, while at all other setting the
output will go/stay inactive. On top of that the samsung PWM settings are
double-buffered, which means the new settings only get applied at the
start of a new PWM cycle.
This results in a race if the PWM is at 100% duty and a driver calls:
pwm_config (pwm, 0, period);
pwm_disable (pwm);
In this case the PWMs output will unexpectedly stay active, unless a new
PWM cycle happened to start between the register writes in _config and
_disable. As far as i can tell this is a regression introduced by 3bdf878,
before that a call to pwm_config would call pwm_samsung_enable which,
while heavy-handed, made sure the expected settings were live.
To resolve this, while not re-introducing the issues 3bdf878 (flickering
as the PWM got reset while in a PWM cycle). Only force an update of the
settings when at 100% duty, which shouldn't have a noticeable effect on
the output but is enough to ensure the behaviour is as expected on
disable.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
Changes since v1:
Fix small issues pointed out by Tomasz Figa
- Correct various coding style issues
- Read the current value of the tcmp register for comparison rather then
using a non-trivial comparison to decide whether the current state was
100% duty
- Move the code to force manual update out into its own function
- Clarify the comment indicating why a manual update is sometimes required
drivers/pwm/pwm-samsung.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index 3e9b583..649f6c4 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -269,12 +269,31 @@ static void pwm_samsung_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
spin_unlock_irqrestore(samsung_pwm_lock, flags);
}
+static void pwm_samsung_manual_update(struct samsung_pwm_chip *chip,
+ struct pwm_device *pwm)
+{
+ unsigned int tcon_chan = to_tcon_channel(pwm-hwpwm);
+ u32 tcon;
+ unsigned long flags;
+
+ spin_lock_irqsave(samsung_pwm_lock, flags);
+
+ tcon = readl(chip-base + REG_TCON);
+ tcon |= TCON_MANUALUPDATE(tcon_chan);
+ writel(tcon, chip-base + REG_TCON);
+
+ tcon = ~TCON_MANUALUPDATE(tcon_chan);
+ writel(tcon, chip-base + REG_TCON);
+
+ spin_unlock_irqrestore(samsung_pwm_lock, flags);
+}
+
static int pwm_samsung_config(struct pwm_chip *chip, struct pwm_device *pwm,
int duty_ns, int period_ns)
{
struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
struct samsung_pwm_channel *chan = pwm_get_chip_data(pwm);
- u32 tin_ns = chan-tin_ns, tcnt, tcmp;
+ u32 tin_ns = chan-tin_ns, tcnt, tcmp, oldtcmp;
/*
* We currently avoid using 64bit arithmetic by using the
@@ -288,6 +307,7 @@ static int pwm_samsung_config(struct pwm_chip *chip,
struct pwm_device *pwm,
return 0;
tcnt = readl(our_chip-base + REG_TCNTB(pwm-hwpwm));
+ oldtcmp = readl(our_chip-base + REG_TCMPB(pwm-hwpwm));
/* We need tick count for calculation, not last tick. */
++tcnt;
@@ -335,6 +355,15 @@ static int pwm_samsung_config(struct pwm_chip *chip,
struct pwm_device *pwm,
writel(tcnt, our_chip-base + REG_TCNTB(pwm-hwpwm));
writel(tcmp, our_chip-base + REG_TCMPB(pwm-hwpwm));
+ /* In case the PWM is currently at 100% duty, force a manual update
+ * to prevent the signal staying high in the pwm is disabled shortly
+ * afer this update (before it autoreloaded the new values) .
+ */
+ if (oldtcmp == (u32) -1) {
+ dev_dbg(our_chip-chip.dev, Forcing manual update);
+ pwm_samsung_manual_update(our_chip, pwm);
+ }
+
chan-period_ns = period_ns;
chan-tin_ns = tin_ns;
chan-duty_ns = duty_ns;
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 Resend] pwm: samsung: Fix output race on disabling
When disabling the samsung PWM the output state remains at the level it
was in the end of a pwm cycle. In other words, calling pwm_disable when
at 100% duty will keep the output active, while at all other setting the
output will go/stay inactive. On top of that the samsung PWM settings are
double-buffered, which means the new settings only get applied at the
start of a new PWM cycle.
This results in a race if the PWM is at 100% duty and a driver calls:
pwm_config (pwm, 0, period);
pwm_disable (pwm);
In this case the PWMs output will unexpectedly stay active, unless a new
PWM cycle happened to start between the register writes in _config and
_disable. As far as i can tell this is a regression introduced by 3bdf878,
before that a call to pwm_config would call pwm_samsung_enable which,
while heavy-handed, made sure the expected settings were live.
To resolve this, while not re-introducing the issues 3bdf878 (flickering
as the PWM got reset while in a PWM cycle). Only force an update of the
settings when at 100% duty, which shouldn't have a noticeable effect on
the output but is enough to ensure the behaviour is as expected on
disable.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
Changes since v1:
Fix small issues pointed out by Tomasz Figa
- Correct various coding style issues
- Read the current value of the tcmp register for comparison rather then
using a non-trivial comparison to decide whether the current state was
100% duty
- Move the code to force manual update out into its own function
- Clarify the comment indicating why a manual update is sometimes required
drivers/pwm/pwm-samsung.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index 3e9b583..649f6c4 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -269,12 +269,31 @@ static void pwm_samsung_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
spin_unlock_irqrestore(samsung_pwm_lock, flags);
}
+static void pwm_samsung_manual_update(struct samsung_pwm_chip *chip,
+ struct pwm_device *pwm)
+{
+ unsigned int tcon_chan = to_tcon_channel(pwm-hwpwm);
+ u32 tcon;
+ unsigned long flags;
+
+ spin_lock_irqsave(samsung_pwm_lock, flags);
+
+ tcon = readl(chip-base + REG_TCON);
+ tcon |= TCON_MANUALUPDATE(tcon_chan);
+ writel(tcon, chip-base + REG_TCON);
+
+ tcon = ~TCON_MANUALUPDATE(tcon_chan);
+ writel(tcon, chip-base + REG_TCON);
+
+ spin_unlock_irqrestore(samsung_pwm_lock, flags);
+}
+
static int pwm_samsung_config(struct pwm_chip *chip, struct pwm_device *pwm,
int duty_ns, int period_ns)
{
struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
struct samsung_pwm_channel *chan = pwm_get_chip_data(pwm);
- u32 tin_ns = chan-tin_ns, tcnt, tcmp;
+ u32 tin_ns = chan-tin_ns, tcnt, tcmp, oldtcmp;
/*
* We currently avoid using 64bit arithmetic by using the
@@ -288,6 +307,7 @@ static int pwm_samsung_config(struct pwm_chip *chip, struct
pwm_device *pwm,
return 0;
tcnt = readl(our_chip-base + REG_TCNTB(pwm-hwpwm));
+ oldtcmp = readl(our_chip-base + REG_TCMPB(pwm-hwpwm));
/* We need tick count for calculation, not last tick. */
++tcnt;
@@ -335,6 +355,15 @@ static int pwm_samsung_config(struct pwm_chip *chip,
struct pwm_device *pwm,
writel(tcnt, our_chip-base + REG_TCNTB(pwm-hwpwm));
writel(tcmp, our_chip-base + REG_TCMPB(pwm-hwpwm));
+ /* In case the PWM is currently at 100% duty, force a manual update
+* to prevent the signal staying high in the pwm is disabled shortly
+* afer this update (before it autoreloaded the new values) .
+*/
+ if (oldtcmp == (u32) -1) {
+ dev_dbg(our_chip-chip.dev, Forcing manual update);
+ pwm_samsung_manual_update(our_chip, pwm);
+ }
+
chan-period_ns = period_ns;
chan-tin_ns = tin_ns;
chan-duty_ns = duty_ns;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] pwm: samsung: Fix output race on disabling
+To Kukjin
Jingoo, Kukjin, could one of you review this patch to ensure it's the
right thing to do on samsung hardware?
On Thu, 2015-01-22 at 22:41 +0100, Sjoerd Simons wrote:
When disabling the samsung PWM the output state remains at the level it
was in the end of a pwm cycle. In other words, calling pwm_disable when
at 100% duty will keep the output active, while at all other setting the
output will go/stay inactive. On top of that the samsung PWM settings are
double-buffered, which means the new settings only get applied at the
start of a new PWM cycle.
This results in a race if the PWM is at 100% duty and a driver calls:
pwm_config (pwm, 0, period);
pwm_disable (pwm);
In this case the PWMs output will unexpectedly stay active, unless a new
PWM cycle happened to start between the register writes in _config and
_disable. As far as i can tell this is a regression introduced by 3bdf878,
before that a call to pwm_config would call pwm_samsung_enable which,
while heavy-handed, made sure the expected settings were live.
To resolve this, while not re-introducing the issues 3bdf878 (flickering
as the PWM got reset while in a PWM cycle). Only force an update of the
settings when at 100% duty, which shouldn't have a noticeable effect on
the output but is enough to ensure the behaviour is as expected on
disable.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
Changes since v1:
Fix small issues pointed out by Tomasz Figa
- Correct various coding style issues
- Read the current value of the tcmp register for comparison rather then
using a non-trivial comparison to decide whether the current state was
100% duty
- Move the code to force manual update out into its own function
- Clarify the comment indicating why a manual update is sometimes required
drivers/pwm/pwm-samsung.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index 3e9b583..649f6c4 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -269,12 +269,31 @@ static void pwm_samsung_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
spin_unlock_irqrestore(samsung_pwm_lock, flags);
}
+static void pwm_samsung_manual_update(struct samsung_pwm_chip *chip,
+ struct pwm_device *pwm)
+{
+ unsigned int tcon_chan = to_tcon_channel(pwm-hwpwm);
+ u32 tcon;
+ unsigned long flags;
+
+ spin_lock_irqsave(samsung_pwm_lock, flags);
+
+ tcon = readl(chip-base + REG_TCON);
+ tcon |= TCON_MANUALUPDATE(tcon_chan);
+ writel(tcon, chip-base + REG_TCON);
+
+ tcon = ~TCON_MANUALUPDATE(tcon_chan);
+ writel(tcon, chip-base + REG_TCON);
+
+ spin_unlock_irqrestore(samsung_pwm_lock, flags);
+}
+
static int pwm_samsung_config(struct pwm_chip *chip, struct pwm_device *pwm,
int duty_ns, int period_ns)
{
struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
struct samsung_pwm_channel *chan = pwm_get_chip_data(pwm);
- u32 tin_ns = chan-tin_ns, tcnt, tcmp;
+ u32 tin_ns = chan-tin_ns, tcnt, tcmp, oldtcmp;
/*
* We currently avoid using 64bit arithmetic by using the
@@ -288,6 +307,7 @@ static int pwm_samsung_config(struct pwm_chip *chip,
struct pwm_device *pwm,
return 0;
tcnt = readl(our_chip-base + REG_TCNTB(pwm-hwpwm));
+ oldtcmp = readl(our_chip-base + REG_TCMPB(pwm-hwpwm));
/* We need tick count for calculation, not last tick. */
++tcnt;
@@ -335,6 +355,15 @@ static int pwm_samsung_config(struct pwm_chip *chip,
struct pwm_device *pwm,
writel(tcnt, our_chip-base + REG_TCNTB(pwm-hwpwm));
writel(tcmp, our_chip-base + REG_TCMPB(pwm-hwpwm));
+ /* In case the PWM is currently at 100% duty, force a manual update
+ * to prevent the signal staying high in the pwm is disabled shortly
+ * afer this update (before it autoreloaded the new values) .
+ */
+ if (oldtcmp == (u32) -1) {
+ dev_dbg(our_chip-chip.dev, Forcing manual update);
+ pwm_samsung_manual_update(our_chip, pwm);
+ }
+
chan-period_ns = period_ns;
chan-tin_ns = tin_ns;
chan-duty_ns = duty_ns;
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH 1/4] mmc: core: add support for hardware reset gpio line
On Fri, 2015-01-30 at 11:37 +0100, Marek Szyprowski wrote: Hello, On 2015-01-29 11:56, Javier Martinez Canillas wrote: On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: Also, I wonder whether we could extend the mmc-pwrseq to cover your case? Did you consider that as an option? I didn't consider mmc-pwrseq yet. For me it looked straightforward to I agree with Ulf that using mmc-pwrseq would be a good solution and in fact I think the pwrseq_simple [0] driver will fit your use case since it supports a reset GPIO pin which is what many WLAN chips attached to a SDIO interface use. Ok, I've checked mmc-prwseq and mmc-pwrseq-simple. I also checked the hardware and it mmc-pwrseq-simple cannot be used directly. Although the signal is called RSTN (on Odroid U3 schema), the eMMC card gets resetted not on low line level, but during the rising edge. This RSTN line is also pulled up by the external resistor. However, the strangest thing is the fact that the default SoC configuration (which is applied during hw reset) for this GPIO line is input, pulled-down. The SoC internal pull-down is stronger than the external pull up, so in the end, during the SoC reboot the RSTN signal is set to zero. Later bootloader disables the internal pull-down. To sum up - to perform proper reboot on Odroid U3/XU3, one need to set RSTN to zero, wait a while and the set it back to 1. To achieve this with mmc-pwrseq-simple, I would need to modify the power_off callback to toggle reset line to zero and back to one. This however might not be desired to other sd/mmc cards used with mmc-pwrseq-simple. I can also provide separate mmc-pwrsrq-odroid driver, which will be very similar to mmc-pwrseq-simple. Apart from the initial odd setup of the SoC pins this is the standard H/W reset operation specified by Jedec 4.4: * pull the reset line down for at least 1us * pull the line up again * Wait at least 200us before sending commands (sdhci_pci_int_hw_reset also implements this). I'm not sure what the determining factor is for a pwrseq driver vs. it being part of the mmc core would be. But if you do a pwrseq driver it shouldn't be board specific e.g. call it mmc-pwrseq-emmc4.4 instead of -odroid? -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 0/2] Fix reboot issue on Odroid boards with eMMC card
On Tue, 2015-01-27 at 09:11 +0100, Marek Szyprowski wrote: Hello, This patchset fixes reboot hang issue on Hardkernel's Odroid boards with eMMC card. Those boards are designed in such a way, that the eMMC nreset signal is routed to SoC GPIO line instead of the board reset logic. To properly restard system, one need to set this line to zero before performing reboot. The initial patches consisted of a complete reset/power off driver, but after further analysis, it turned out that only eMMC nreset line control logic is specific for those boards. Everything else can be done by generic Exynos code, so the code has been moved to Exynos DW MMC driver. This seems a general board design quirk, rather then an exynos specific one. Potentially better to have this in the mmc core so it can be re-used by non-exynos boards? A very quick peek at the schematic for the hardkernel C1 (amlogic based), shows that for that board the eMMC reset line is hooked up to an SoC gpio line as well. (Although ofcourse, it may not need to be reset before a warm restart depending on what the amlogic rom code does). Random side-note, at least the samsung peach chromebooks are also hooked up this way. But don't run into this issue as they load their initial stages from flash rather then the eMMC. Best regards Marek Szyprowski Samsung RD Institute Poland Changelog: initial version: http://thread.gmane.org/gmane.linux.power-management.general/51855/ Path summary: Marek Szyprowski (2): mmc: dw_mmc-exynos: add support for controlling emmc reset pin ARM: dts: exynos*-odroid*: add eMMC reset line .../devicetree/bindings/mmc/exynos-dw-mshc.txt | 6 +++ arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 1 + arch/arm/boot/dts/exynos5422-odroidxu3.dts | 1 + drivers/mmc/host/dw_mmc-exynos.c | 43 +- 4 files changed, 50 insertions(+), 1 deletion(-) smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] ARM: dts: exynos5422-odroidxu3: reduce total RAM by 22 MiB
On Fri, 2015-01-23 at 15:35 +0900, Kukjin Kim wrote:
Marek Szyprowski wrote:
Last 22 MiB is RAM is reserved by secure monitor code and cannot be
accessed from Linux kernel, so adjust total RAM size to 0x7EA0
(2 GiB - 22 MiB). This fixes random 'imprecise kernel abort' kernel
failures.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index f6fc9442f631..50843208860d 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -18,7 +18,7 @@
compatible = hardkernel,odroid-xu3, samsung,exynos5800,
samsung,exynos5;
memory {
- reg = 0x4000 0x8000;
+ reg = 0x4000 0x7EA0;
};
chosen {
--
Just checked hardkernels bootloader which defines:
#define CONFIG_TRUSTZONE_RESERVED_DRAM 0x160
So looks good,
Reviewed-By: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Hi,
Maybe is it related to the SoC not only for odriodxu3 board. If so, following
would be better?
---88---
diff --git a/arch/arm/boot/dts/exynos5800.dtsi
b/arch/arm/boot/dts/exynos5800.dtsi
index c0bb356..54840e3 100644
--- a/arch/arm/boot/dts/exynos5800.dtsi
+++ b/arch/arm/boot/dts/exynos5800.dtsi
@@ -13,6 +13,8 @@
* published by the Free Software Foundation.
*/
+/memreserve/ 0x8000 0x160;
+
#include exynos5420.dtsi
/ {
---88---
- Kukjin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH] ARM: dts: Add sd0_rst pinctrl node to exynos5420
On Fri, 2015-01-23 at 15:36 +0100, Javier Martinez Canillas wrote: Hello Jaehoon, On Fri, Jan 23, 2015 at 3:23 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: Add sd0_rst node to exynos5420-pinctrl.dtsi. (It's used on odroid-xu3 board) It would be good to mention which device needs this pinctrl line. Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com --- arch/arm/boot/dts/exynos5420-pinctrl.dtsi |5 + If this pin is used by the Odroid XU3 board, shouldn't be defined in the exynos5422-odroidxu3.dts instead? It's not just used by the XU3 though, it's also hooked up on the peach pi chromebook for example and i would expect it to be hooked up on most board with an eMMC This change is consistent with most of the special purpose GPIO pins defined in that file, so i don't see the problem with including it in that pinctrl file -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] ARM: dts: Add sd0_rst pinctrl node to exynos5420
On Fri, 2015-01-23 at 23:23 +0900, Jaehoon Chung wrote:
Add sd0_rst node to exynos5420-pinctrl.dtsi.
(It's used on odroid-xu3 board)
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
arch/arm/boot/dts/exynos5420-pinctrl.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
index ba686e4..315cad7 100644
--- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
@@ -194,6 +194,11 @@
samsung,pin-drv = 3;
};
+ sd0_rst: sd0-rst {
+ samsung,pins = gpd1-0;
+ samsung,pin-function = 1;
I think this should be samsung,pin-function = 2; for that
functionality.
--
Sjoerd Simons sjoerd.sim...@collabora.co.uk
Collabora Ltd.
smime.p7s
Description: S/MIME cryptographic signature
[PATCH v2] pwm: samsung: Fix output race on disabling
When disabling the samsung PWM the output state remains at the level it
was in the end of a pwm cycle. In other words, calling pwm_disable when
at 100% duty will keep the output active, while at all other setting the
output will go/stay inactive. On top of that the samsung PWM settings are
double-buffered, which means the new settings only get applied at the
start of a new PWM cycle.
This results in a race if the PWM is at 100% duty and a driver calls:
pwm_config (pwm, 0, period);
pwm_disable (pwm);
In this case the PWMs output will unexpectedly stay active, unless a new
PWM cycle happened to start between the register writes in _config and
_disable. As far as i can tell this is a regression introduced by 3bdf878,
before that a call to pwm_config would call pwm_samsung_enable which,
while heavy-handed, made sure the expected settings were live.
To resolve this, while not re-introducing the issues 3bdf878 (flickering
as the PWM got reset while in a PWM cycle). Only force an update of the
settings when at 100% duty, which shouldn't have a noticeable effect on
the output but is enough to ensure the behaviour is as expected on
disable.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
Changes since v1:
Fix small issues pointed out by Tomasz Figa
- Correct various coding style issues
- Read the current value of the tcmp register for comparison rather then
using a non-trivial comparison to decide whether the current state was
100% duty
- Move the code to force manual update out into its own function
- Clarify the comment indicating why a manual update is sometimes required
drivers/pwm/pwm-samsung.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index 3e9b583..649f6c4 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -269,12 +269,31 @@ static void pwm_samsung_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
spin_unlock_irqrestore(samsung_pwm_lock, flags);
}
+static void pwm_samsung_manual_update(struct samsung_pwm_chip *chip,
+ struct pwm_device *pwm)
+{
+ unsigned int tcon_chan = to_tcon_channel(pwm-hwpwm);
+ u32 tcon;
+ unsigned long flags;
+
+ spin_lock_irqsave(samsung_pwm_lock, flags);
+
+ tcon = readl(chip-base + REG_TCON);
+ tcon |= TCON_MANUALUPDATE(tcon_chan);
+ writel(tcon, chip-base + REG_TCON);
+
+ tcon = ~TCON_MANUALUPDATE(tcon_chan);
+ writel(tcon, chip-base + REG_TCON);
+
+ spin_unlock_irqrestore(samsung_pwm_lock, flags);
+}
+
static int pwm_samsung_config(struct pwm_chip *chip, struct pwm_device *pwm,
int duty_ns, int period_ns)
{
struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
struct samsung_pwm_channel *chan = pwm_get_chip_data(pwm);
- u32 tin_ns = chan-tin_ns, tcnt, tcmp;
+ u32 tin_ns = chan-tin_ns, tcnt, tcmp, oldtcmp;
/*
* We currently avoid using 64bit arithmetic by using the
@@ -288,6 +307,7 @@ static int pwm_samsung_config(struct pwm_chip *chip, struct
pwm_device *pwm,
return 0;
tcnt = readl(our_chip-base + REG_TCNTB(pwm-hwpwm));
+ oldtcmp = readl(our_chip-base + REG_TCMPB(pwm-hwpwm));
/* We need tick count for calculation, not last tick. */
++tcnt;
@@ -335,6 +355,15 @@ static int pwm_samsung_config(struct pwm_chip *chip,
struct pwm_device *pwm,
writel(tcnt, our_chip-base + REG_TCNTB(pwm-hwpwm));
writel(tcmp, our_chip-base + REG_TCMPB(pwm-hwpwm));
+ /* In case the PWM is currently at 100% duty, force a manual update
+* to prevent the signal staying high in the pwm is disabled shortly
+* afer this update (before it autoreloaded the new values) .
+*/
+ if (oldtcmp == (u32) -1) {
+ dev_dbg(our_chip-chip.dev, Forcing manual update);
+ pwm_samsung_manual_update(our_chip, pwm);
+ }
+
chan-period_ns = period_ns;
chan-tin_ns = tin_ns;
chan-duty_ns = duty_ns;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] ARM: dts: exynos5422-odroidxu3: add on-board INA231 sensors
On Wed, 2015-01-14 at 17:08 -0800, Kevin Hilman wrote:
From: Kevin Hilman khil...@linaro.org
The odroid-xu3 has 4 INA231 current sensors on board which can be
accessed from the Linux via the hwmon interface.
There is one sensor for each of these power rails:
- A15 cluster: VDD_ARM
- A7 cluster: VDD_KFC
- GPU: VDD_G3D
- memory: VDD_MEM
In addition to adding the sensors, LDO26 from the PMIC needs to be
enabled because it's powering these sensor.
I haven't tested whether the sensor values are correct, but based on the
schematics the hardkernel dts this describes the hardware correctly.
Reviewed-By: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Signed-off-by: Kevin Hilman khil...@linaro.org
---
v2: use ti,ina231 as compatible string.
Applies on top of ARM: dts: Add dts file for odroid XU3 board from Sjoerd
Simons.
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 39
++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index c29123c0734d..50353d023225 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -174,6 +174,13 @@
regulator-always-on;
};
+ ldo26_reg: LDO26 {
+ regulator-name = vdd_ldo26;
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ regulator-always-on;
+ };
+
buck1_reg: BUCK1 {
regulator-name = vdd_mif;
regulator-min-microvolt = 80;
@@ -257,6 +264,38 @@
};
};
+ i2c_0: i2c@12C6 {
+ status = okay;
+
+ /* A15 cluster: VDD_ARM */
+ ina231@40 {
+ compatible = ti,ina231;
+ reg = 0x40;
+ shunt-resistor = 1;
+ };
+
+ /* memory: VDD_MEM */
+ ina231@41 {
+ compatible = ti,ina231;
+ reg = 0x41;
+ shunt-resistor = 1;
+ };
+
+ /* GPU: VDD_G3D */
+ ina231@44 {
+ compatible = ti,ina231;
+ reg = 0x44;
+ shunt-resistor = 1;
+ };
+
+ /* A7 cluster: VDD_KFC */
+ ina231@45 {
+ compatible = ti,ina231;
+ reg = 0x45;
+ shunt-resistor = 1;
+ };
+ };
+
i2c_2: i2c@12C8 {
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support
On Mon, 2015-01-19 at 15:01 -0200, Gustavo Padovan wrote: 2015-01-19 Thierry Reding thierry.red...@gmail.com: On Mon, Jan 19, 2015 at 11:27:52AM +0100, Javier Martinez Canillas wrote: Hello Thierry, On 01/05/2015 02:50 PM, Thierry Reding wrote: On Fri, Jan 02, 2015 at 01:10:14PM +, Daniel Stone wrote: Ajay's series don't apply cleanly anymore because it has been a while since he posted it but he can rebase on top of 3.19-rc1 once it is released and re-resend. Do you have any plans to rebase this so it's ready for merging? Thierry, Daniel, Dave - whose tree would this be best to merge through? The plan is for me to take the bridge patches through the drm/panel tree. I'm going to look at these patches again later this week but from a very quick peek there don't seem to be any major issues left. I know you probably are very busy but it would be great if you can take a look to this series to avoid another kernel release to be missed since we are already at v3.19-rc5. Only this version was posted 2 months ago and the first version of the series was sent on May, 2014 so it has been on the list for almost a year now... Tomi and Laurent had already agreed with the DT binging so I think that we can already merge these and if there are any remaining issues, those can be fixed during the 3.20 -rc cycle. I see only a single Tested-by on this series and that seems to be with a bunch of out-of-tree patches applied on top. Does this now actually work applied on top of upstream? Also it seems like many people actually want this to get merged but there's been no Reviewed-bys and only a single Tested-by? Is that as good as it's going to get? I've been using this series on top of exynos-drm for more than a month and it works fine for me so.. Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk Same here, just test-booted on my snow with just these patch on top of 3.19-rc5 and got a nicely working display. Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 2/9] hwmon: dts: Doc: Add DTS doc to explain how to use PWM FAN as a cooling device
On Wed, 2015-01-14 at 14:56 +0100, Lukasz Majewski wrote: Hi Sjoerd, Could you review v2 of this patch series? http://www.spinics.net/lists/devicetree/msg63159.html I skimmed it yesterday, I'll try to find some time to send you my review comments later in the week/start of next. Do you happen to have a git branch with these patches in? That would make it convenient for me to give your patches a spin on my XU3 -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] ARM: dts: exynos5422-odroidxu3: add INA2xx sensors
Hey kevin,
On Tue, 2015-01-13 at 16:03 -0800, Kevin Hilman wrote:
From: Kevin Hilman khil...@linaro.org
The odroid-xu3 has 4 INA231 current sensors on board which can be
accessed from the Linux via the hwmon interface.
There is one sensor for each of these power rails:
- A15 cluster: VDD_ARM
- A7 cluster: VDD_KFC
- GPU: VDD_G3D
- memory: VDD_MEM
In addition to adding the sensors, LDO26 from the PMIC needs to be
enabled because it's powering these sensor.
Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Signed-off-by: Kevin Hilman khil...@linaro.org
---
Applies on top of ARM: dts: Add dts file for odroid XU3 board from Sjoerd
Simons.
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 39
++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index c29123c0734d..7874da20939f 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -257,6 +264,38 @@
};
};
+ i2c_0: i2c@12C6 {
+ status = okay;
+
+ /* A15 cluster: VDD_ARM */
+ ina220@40 {
^ ina231@40 ?
+ compatible = ti,ina230;
This feels incredibly nitpicky, but would it not better to use ti,ina231
as it's an INA231 chip not a INA230? (And add the compatibility string
to the driver)
--
Sjoerd Simons sjoerd.sim...@collabora.co.uk
Collabora Ltd.
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH v2] ARM: dts: Add dts file for odroid XU3 board
On Wed, 2015-01-07 at 23:49 +, Jonathan Stone -SISA wrote: On On Wed, 2015-01-07 at 18:37 +, Sjoerd Simons writes wrote: On Wed, 2015-01-07 at 18:37 +, Anand Moon wrote: [...] Only 4 core cpu's are on my board. Also CpuFreq is not working. Can you share some point on this. The defconfig is using the bL switcher, which pairs up big and little cores to make them appear as one core.. So for 8 real cores, you'll get 4 virtual cores. That configuration is appropriate for the 5420, which allegedly has a hardware bug in the cache-coherence between the Cortex-A7 block and the Cortex-A15 block. Newer Exynos 5 SoCs -- 5422/5800, 5620, etc -- don't have that bug. The scheduler should configured to do HMP on all 8 (or 6) cores. I don't have a 5410, but I assume it has the same bug as the 5420. Yes the kernel/scheduler could be configured like that, but exynos_defconfig turns on bL rather then HMP. Now it's not unthinkable to add code/dts properties to select the right/preferred scheduling strategy depending on the board (HMP vs. bL). But proper HMP scheduling is still a work in progress in mainline and iirc specifically on the XU3 there are open issue wrt. MCPM and its secure firmware. I've added Kevin to the CC as he's been working on this topic so should know the status a lot better then i do. The XU3 kernel supplied by HardKernel shows all 8 cores, and does HMP scheduling across all 8. Yes, that's independant of the dts though as mentioned above. Also there are still opne issues to booting up all cores on an XU3 afaik. See http://www.spinics.net/lists/linux-samsung-soc/msg39523.html I tried v1.0 of the Odroid-XU3 DTB patch, applied to linux-next 20150107. I'm only seeing 1 core running on my Odroid-XU3. The USB 3.0 port works (great!) but I'm not getting any HDMI output. I didn't try DisplayPort. I'll gladly try v2 of the patch on an XU3; is there a better base to apply the patch to? HDMI output is broken on all exynos boards in mainline atm. For exynos 5, see the thread here: http://www.spinics.net/lists/linux-samsung-soc/msg40708.html As far as a i know with the DTS as posted (just posted v3 with a small improvement), all base functionality that can work on mainline (MMC/SD, network, USB2, USB3) works. Some less important bits (fan control power sensors) are outstanding, but that really shouldn't block the merge of the DTS. -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
[PATCH v3] ARM: dts: Add dts file for odroid XU3 board
Add DTS for the Hardkernel Odroid XU3. The name of the DTS file is kept the
same as the vendors naming, which means it's prefixed with exynos5422
instead of exynos5800 as the SoC name even though it includes the
exyno5800 dtsi.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
Changes since v1:
* Add chosen/linux,stdout-path to point the serial console device
* Change memory start offset to 0x4000 to match the vendors DTS (pointed
out by Heesub Shin)
* Declare base address size for the memory banks to be used by the MFC
Changes since v2:
* Correct hdmi supplies (spotted by Joonyoung Shim). This currently doesn't
have a practical impact as all supplies are always-on, but makes the dts
match the schematics.
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 332 +
2 files changed, 333 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5422-odroidxu3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 91bd5bd..df397c2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -98,6 +98,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos3250-monk.dtb \
exynos5420-arndale-octa.dtb \
exynos5420-peach-pit.dtb \
exynos5420-smdk5420.dtb \
+ exynos5422-odroidxu3.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb \
exynos5800-peach-pi.dtb
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
new file mode 100644
index 000..c29123c
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -0,0 +1,332 @@
+/*
+ * Hardkernel Odroid XU3 board device tree source
+ *
+ * Copyright (c) 2014 Collabora Ltd.
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+#include exynos5800.dtsi
+
+/ {
+ model = Hardkernel Odroid XU3;
+ compatible = hardkernel,odroid-xu3, samsung,exynos5800,
samsung,exynos5;
+
+ memory {
+ reg = 0x4000 0x8000;
+ };
+
+ chosen {
+ linux,stdout-path = serial_2;
+ };
+
+ fimd@1440 {
+ status = okay;
+ };
+
+ firmware@02073000 {
+ compatible = samsung,secure-firmware;
+ reg = 0x02073000 0x1000;
+ };
+
+ fixed-rate-clocks {
+ oscclk {
+ compatible = samsung,exynos5420-oscclk;
+ clock-frequency = 2400;
+ };
+ };
+
+ hsi2c_4: i2c@12CA {
+ status = okay;
+
+ s2mps11_pmic@66 {
+ compatible = samsung,s2mps11-pmic;
+ reg = 0x66;
+ s2mps11,buck2-ramp-delay = 12;
+ s2mps11,buck34-ramp-delay = 12;
+ s2mps11,buck16-ramp-delay = 12;
+ s2mps11,buck6-ramp-enable = 1;
+ s2mps11,buck2-ramp-enable = 1;
+ s2mps11,buck3-ramp-enable = 1;
+ s2mps11,buck4-ramp-enable = 1;
+
+ s2mps11_osc: clocks {
+ #clock-cells = 1;
+ clock-output-names = s2mps11_ap,
+ s2mps11_cp, s2mps11_bt;
+ };
+
+ regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = vdd_ldo1;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ regulator-always-on;
+ };
+
+ ldo3_reg: LDO3 {
+ regulator-name = vdd_ldo3;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ };
+
+ ldo5_reg: LDO5 {
+ regulator-name = vdd_ldo5;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ };
+
+ ldo6_reg: LDO6 {
+ regulator-name = vdd_ldo6;
+ regulator-min-microvolt = 100
[PATCH RESEND] ARM: EXYNOS: Recognize Samsung MFC v8 devices
Also setup memory allocations for version 8 of the MFC as present in Samsung Exynos 5422/5800 SoCs Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- arch/arm/mach-exynos/exynos.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c index c13d083..b343a1a 100644 --- a/arch/arm/mach-exynos/exynos.c +++ b/arch/arm/mach-exynos/exynos.c @@ -282,6 +282,7 @@ static void __init exynos_reserve(void) samsung,mfc-v5, samsung,mfc-v6, samsung,mfc-v7, + samsung,mfc-v8, }; for (i = 0; i ARRAY_SIZE(mfc_mem); i++) -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND] pwm: samsung: Fix output race on disabling
When disabling the samsung PWM the output state remains at the level it
was in the end of a pwm cycle. In other words, calling pwm_disable when
at 100% duty will keep the output active, while at all other setting the
output will go/stay inactive. On top of that the samsung PWM settings are
double-buffered, which means the new settings only get applied at the
start of a new PWM cycle.
This results in a race if the PWM is at 100% duty and a driver calls:
pwm_config (pwm, 0, period);
pwm_disable (pwm);
In this case the PWMs output will unexpectedly stay active, unless a new
PWM cycle happened to start between the register writes in _config and
_disable. As far as i can tell this is a regression introduced by 3bdf878,
before that a call to pwm_config would call pwm_samsung_enable which,
while heavy-handed, made sure the expected settings were live.
To resolve this, while not re-introducing the issues 3bdf878 (flickering
as the PWM got reset while in a PWM cycle). Only force an update of the
settings when at 100% duty, which shouldn't have a noticeable effect on
the output but is enough to ensure the behaviour is as expected on
disable.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/pwm/pwm-samsung.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index 3e9b583..3e252dc 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -335,6 +335,27 @@ static int pwm_samsung_config(struct pwm_chip *chip,
struct pwm_device *pwm,
writel(tcnt, our_chip-base + REG_TCNTB(pwm-hwpwm));
writel(tcmp, our_chip-base + REG_TCMPB(pwm-hwpwm));
+ /* In case the PWM is currently at 100% duty, trigger a manual update to
+* prevent unexpected results when disabling the pwm */
+ if (chan-period_ns/chan-tin_ns == chan-duty_ns/chan-tin_ns) {
+ unsigned int tcon_chan = to_tcon_channel(pwm-hwpwm);
+ u32 tcon;
+ unsigned long flags;
+
+ dev_dbg(our_chip-chip.dev, Forcing manual update);
+
+ spin_lock_irqsave(samsung_pwm_lock, flags);
+
+ tcon = readl(our_chip-base + REG_TCON);
+ tcon |= TCON_MANUALUPDATE(tcon_chan);
+ writel(tcon, our_chip-base + REG_TCON);
+
+ tcon = ~TCON_MANUALUPDATE(tcon_chan);
+ writel(tcon, our_chip-base + REG_TCON);
+
+ spin_unlock_irqrestore(samsung_pwm_lock, flags);
+ }
+
chan-period_ns = period_ns;
chan-tin_ns = tin_ns;
chan-duty_ns = duty_ns;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] ARM: dts: Add dts file for odroid XU3 board
] systemd-udevd[1923]: starting version 204
[ 32.854190] Bluetooth: Core ver 2.19
[ 32.856710] NET: Registered protocol family 31
[ 32.856733] Bluetooth: HCI device and connection manager initialized
[ 32.857604] Bluetooth: HCI socket layer initialized
[ 32.877598] Bluetooth: L2CAP socket layer initialized
[ 32.879515] Bluetooth: SCO socket layer initialized
[ 33.282331] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 33.282356] Bluetooth: BNEP filters: protocol multicast
[ 33.282600] Bluetooth: BNEP socket layer initialized
[ 33.371899] _cpu_up: attempt to bring up CPU 2 failed
[ 33.380836] Bluetooth: RFCOMM TTY layer initialized
[ 33.381088] Bluetooth: RFCOMM socket layer initialized
[ 33.381439] Bluetooth: RFCOMM ver 1.11
[ 33.410276] _cpu_up: attempt to bring up CPU 3 failed
[ 33.414848] _cpu_up: attempt to bring up CPU 4 failed
[ 33.419857] _cpu_up: attempt to bring up CPU 1 failed
[ 38.518916] NET: Registered protocol family 10
[ 46.590494] init: failsafe main process (2550) killed by TERM signal
[ 50.596528] smsc95xx 5-1.1:1.0 eth0: hardware isn't capable of remote
wakeup
-Anand Moon
On Monday, January 5, 2015 9:00 PM, Sjoerd Simons
sjoerd.sim...@collabora.co.uk wrote:
On Mon, 2015-01-05 at 17:18 +0900, Joonyoung Shim wrote:
Hi Sjoerd,
On 12/05/2014 04:27 AM, Sjoerd Simons wrote:
Add DTS for the Hardkernel Odroid XU3. The name of the DTS file is kept
the
same as the vendors naming, which means it's prefixed with exynos5422
instead of exynos5800 as the SoC name even though it includes the
exyno5800 dtsi.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
Changes since v1:
* Add chosen/linux,stdout-path to point the serial console device
* Change memory start offset to 0x4000 to match the vendors DTS
(pointed
out by Heesub Shin)
* Declare base address size for the memory banks to be used by the MFC
Kevin, Tyler, even though the changes are small i didn't want to just
stick
your Tested-By on. Could you both be so kind to retest this on your XU3's
?
Heesub, I would still love to know the reason for having the memory start
address at 0x4000 for this board?
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 332
+
2 files changed, 333 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5422-odroidxu3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 38c89ca..0a898cc 100644
+
+hdmi {
+status = okay;
+hpd-gpio = gpx3 7 0;
+pinctrl-names = default;
+pinctrl-0 = hdmi_hpd_irq;
+
+vdd_osc-supply = ldo10_reg;
+vdd_pll-supply = ldo8_reg;
+vdd-supply = ldo8_reg;
ldo10 and ldo8 are right? I think ldo7 and ldo6 are related with hdmi
from schematic.
Nice catch. I followed hardkernels dts here, which refers to ldo10
ldo8, however double-checking the schematics indeed indicate that ldo7
and ldo6 are used the HDMI supplies.
I'll do some testing and follow-up
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH] ARM: EXYNOS: do not try to map PMU for exynos5440
On Mon, 2015-01-05 at 14:44 +0530, Pankaj Dubey wrote: Commit id: 2e94ac42898f84d76e3c21dd91bc is not taking care of mapping of exynos5440 PMU register which will result in kernel panic on exynos5440. As exynos5440 DTS does not have PMU node, and also we are skipping exynos_pm_init in case of exynos5440, let's avoid mapping of exynos5440 PMU. Reported-by: Ming Lei tom.leim...@gmail.com Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/exynos.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c index c13d083..1891b8c 100644 --- a/arch/arm/mach-exynos/exynos.c +++ b/arch/arm/mach-exynos/exynos.c @@ -208,7 +208,8 @@ static void __init exynos_init_irq(void) * DT is not unflatten so we can't use DT APIs before * init_irq */ - exynos_map_pmu(); + if (!of_machine_is_compatible(samsung,exynos5440)) + exynos_map_pmu(); } static void __init exynos_dt_machine_init(void) Why the blacklist approach rather then simply making exynos_map_pmu exit rather then panicing if it couldn't find a pmu node in the dts? -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 2/9] hwmon: dts: Doc: Add DTS doc to explain how to use PWM FAN as a cooling device
Hey Lukasz, Blame the holiday season for my late reply ;) On Fri, 2014-12-19 at 17:13 +0100, Lukasz Majewski wrote: Hi Guenter, On Fri, Dec 19, 2014 at 04:32:24PM +0100, Lukasz Majewski wrote: Hi Sjoerd, Thanks for your feedback and sorry for a late reply. On Thu, 2014-12-18 at 11:13 +0100, Lukasz Majewski wrote: Several new properties to allow PWM fan working as a cooling device have been combined into this single commit. Signed-off-by: Lukasz Majewski l.majew...@samsung.com --- .../devicetree/bindings/hwmon/pwm-fan.txt | 28 ++ 1 file changed, 28 insertions(+) diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt index 610757c..3877810 100644 --- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt +++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt @@ -3,10 +3,38 @@ Bindings for a fan connected to the PWM lines Required properties: - compatible : pwm-fan - pwms : the PWM that is used to control the PWM fan +- cooling-pwm-values : PWM duty cycle values relative to + cooling-max-pwm-value correspondig to + proper cooling states +- default-pulse-width : Property specifying default pulse width for FAN + at system boot (zero to disable FAN on boot). + Allowed range is 0 to 255 The 0..255 range seems somewhat random. Would be nicer to either use the approach of pwm-backlight (iotw, have the range go from the first to the last entry of cooling-pwm-values) I'm OK to change the default-pulse-width to be similar to default-brightness-level (as it is in Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt) or simply have be the duty lenght in NS as entries instead of the current indirection. I'd prefer to keep the indirection - as it is utilized in the current pwm-fan.c driver. FWIW, devicetree information is supposed to be implementation independent. So this is a poor argument. Many other pwm drivers use the indirection - e.g. mentioned pwm-backlight. I don't specifically mind the indirection, i was just thinking out loud whether it added value (but if it's quite common, might indeed be good to keep the pattern). What i do dislike is the number of levels is being set to an arbitrary levels, as that will very rarely match the actual number of distinct pwm levels you One thing though, when following the pattern of the pwm-backlight driver; In pwm-backlight the highest index of brightness-levels is always 100% duty cycle.. On e.g. XU3 the vendor kernel never drives the fan at 100% duty (maximum of 91%). So it would be nice if the dt bindigns could model that e.g. by having: pwm-levels = 20; // 21 distinct pwm levels valid-pwm-level = 5 15 18; /* 5 15 and 18 are usable levels - pwm will default to highest level */ Enabling pan to full RPM was the default behaviour in the current pwm-fan.c file. To be honest, there is no need to enable fan to full RPM speed in this board for following reasons: 1. In Odroid the FAN is optional (stacked on top of a heat sink) - very often it is just enough to only have the heat sink. 2. Odroid has thermal enabled by default and IMHO it would be more feasible to allow thermal to control fan from the very beginning. However, I can also understand if the policy for hwmon implies a rule to enable by default all fans to full RPM speed. Why and how does that all suggest that the current default behavior should be changed ? I wanted to avoid the unpleasant sound for full speed fan when thermal is not enabled by default. But as I said, I fully understand the policy and I would be happy to comply with it as thermal should reduce the fan speed anyway at boot time. Yeah, what happens on my XU3 is that u-boot sets the pwm to 100% duty and the thermal infrastructure turns it off as soon as it gets into control, which works quite nicely (and keeps my sanity as that fan at 100% is *loud*)... So if you want to avoid unpleasant sounds, just build with thermal :p -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v2] ARM: dts: Add dts file for odroid XU3 board
On Mon, 2015-01-05 at 17:18 +0900, Joonyoung Shim wrote:
Hi Sjoerd,
On 12/05/2014 04:27 AM, Sjoerd Simons wrote:
Add DTS for the Hardkernel Odroid XU3. The name of the DTS file is kept the
same as the vendors naming, which means it's prefixed with exynos5422
instead of exynos5800 as the SoC name even though it includes the
exyno5800 dtsi.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
Changes since v1:
* Add chosen/linux,stdout-path to point the serial console device
* Change memory start offset to 0x4000 to match the vendors DTS
(pointed
out by Heesub Shin)
* Declare base address size for the memory banks to be used by the MFC
Kevin, Tyler, even though the changes are small i didn't want to just stick
your Tested-By on. Could you both be so kind to retest this on your XU3's ?
Heesub, I would still love to know the reason for having the memory start
address at 0x4000 for this board?
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 332
+
2 files changed, 333 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5422-odroidxu3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 38c89ca..0a898cc 100644
+
+hdmi {
+ status = okay;
+ hpd-gpio = gpx3 7 0;
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_hpd_irq;
+
+ vdd_osc-supply = ldo10_reg;
+ vdd_pll-supply = ldo8_reg;
+ vdd-supply = ldo8_reg;
ldo10 and ldo8 are right? I think ldo7 and ldo6 are related with hdmi
from schematic.
Nice catch. I followed hardkernels dts here, which refers to ldo10
ldo8, however double-checking the schematics indeed indicate that ldo7
and ldo6 are used the HDMI supplies.
I'll do some testing and follow-up
--
Sjoerd Simons sjoerd.sim...@collabora.co.uk
Collabora Ltd.
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH 2/9] hwmon: dts: Doc: Add DTS doc to explain how to use PWM FAN as a cooling device
On Thu, 2014-12-18 at 11:13 +0100, Lukasz Majewski wrote:
Several new properties to allow PWM fan working as a cooling device have been
combined into this single commit.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
.../devicetree/bindings/hwmon/pwm-fan.txt | 28
++
1 file changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
index 610757c..3877810 100644
--- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
+++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
@@ -3,10 +3,38 @@ Bindings for a fan connected to the PWM lines
Required properties:
- compatible : pwm-fan
- pwms : the PWM that is used to control the PWM fan
+- cooling-pwm-values : PWM duty cycle values relative to
+ cooling-max-pwm-value correspondig to
+ proper cooling states
+- default-pulse-width : Property specifying default pulse width for FAN
+ at system boot (zero to disable FAN on boot).
+ Allowed range is 0 to 255
The 0..255 range seems somewhat random. Would be nicer to either use the
approach of pwm-backlight (iotw, have the range go from the first to the
last entry of cooling-pwm-values) or simply have be the duty lenght in
NS as entries instead of the current indirection.
I assumed your cooling-pwm-values are a [0..255] range as well instead
of nanoseconds (would be good to make that more clear)?
Also having more consistent names would be nice.. To take pwm-backlight
as inspiration, cooling-levels and default-cooling-level would make it
more clear the second property picks a default setting from the first
one.
One thing i do wonder, is having an explicit default setting useful?
Should it not default to maximum cooling unless otherwise configured by
either the thermal framework or sysfs ?
+Thorough description of the following bindings:
+ cooling-min-state = 0;
+ cooling-max-state = 3;
+ #cooling-cells = 2;
+ thermal-zone {
+ cpu_thermal: cpu-thermal {
+ cooling-maps {
+ map0 {
+ trip = cpu_alert1;
+ cooling-device = fan0 0 1;
+ };
+ };
+ };
+
+for PWM FAN used as cooling device can be found at:
+./Documentation/devicetree/bindings/thermal/thermal.txt
Example:
pwm-fan {
compatible = pwm-fan;
status = okay;
pwms = pwm 0 1 0;
+ cooling-min-state = 0;
+ cooling-max-state = 3;
+ #cooling-cells = 2;
+ cooling-pwm-values = 0 102 170 255;
+ default-pulse-width = 0;
};
smime.p7s
Description: S/MIME cryptographic signature
[PATCH v2] ARM: dts: Add dts file for odroid XU3 board
Add DTS for the Hardkernel Odroid XU3. The name of the DTS file is kept the
same as the vendors naming, which means it's prefixed with exynos5422
instead of exynos5800 as the SoC name even though it includes the
exyno5800 dtsi.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
Changes since v1:
* Add chosen/linux,stdout-path to point the serial console device
* Change memory start offset to 0x4000 to match the vendors DTS (pointed
out by Heesub Shin)
* Declare base address size for the memory banks to be used by the MFC
Kevin, Tyler, even though the changes are small i didn't want to just stick
your Tested-By on. Could you both be so kind to retest this on your XU3's ?
Heesub, I would still love to know the reason for having the memory start
address at 0x4000 for this board?
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 332 +
2 files changed, 333 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5422-odroidxu3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 38c89ca..0a898cc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -86,6 +86,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5420-arndale-octa.dtb \
exynos5420-peach-pit.dtb \
exynos5420-smdk5420.dtb \
+ exynos5422-odroidxu3.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb \
exynos5800-peach-pi.dtb
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
new file mode 100644
index 000..0dc9cf8
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -0,0 +1,332 @@
+/*
+ * Hardkernel Odroid XU3 board device tree source
+ *
+ * Copyright (c) 2014 Collabora Ltd.
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+#include exynos5800.dtsi
+
+/ {
+ model = Hardkernel Odroid XU3;
+ compatible = hardkernel,odroid-xu3, samsung,exynos5800,
samsung,exynos5;
+
+ memory {
+ reg = 0x4000 0x8000;
+ };
+
+ chosen {
+ linux,stdout-path = serial_2;
+ };
+
+ fimd@1440 {
+ status = okay;
+ };
+
+ firmware@02073000 {
+ compatible = samsung,secure-firmware;
+ reg = 0x02073000 0x1000;
+ };
+
+ fixed-rate-clocks {
+ oscclk {
+ compatible = samsung,exynos5420-oscclk;
+ clock-frequency = 2400;
+ };
+ };
+
+ hsi2c_4: i2c@12CA {
+ status = okay;
+
+ s2mps11_pmic@66 {
+ compatible = samsung,s2mps11-pmic;
+ reg = 0x66;
+ s2mps11,buck2-ramp-delay = 12;
+ s2mps11,buck34-ramp-delay = 12;
+ s2mps11,buck16-ramp-delay = 12;
+ s2mps11,buck6-ramp-enable = 1;
+ s2mps11,buck2-ramp-enable = 1;
+ s2mps11,buck3-ramp-enable = 1;
+ s2mps11,buck4-ramp-enable = 1;
+
+ s2mps11_osc: clocks {
+ #clock-cells = 1;
+ clock-output-names = s2mps11_ap,
+ s2mps11_cp, s2mps11_bt;
+ };
+
+ regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = vdd_ldo1;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ regulator-always-on;
+ };
+
+ ldo3_reg: LDO3 {
+ regulator-name = vdd_ldo3;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ };
+
+ ldo5_reg: LDO5 {
+ regulator-name = vdd_ldo5;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ };
+
+ ldo6_reg: LDO6 {
+ regulator-name = vdd_ldo6
[PATCH] ARM: EXYNOS: Recognize Samsung MFC v8 devices
Also setup memory allocations for version 8 of the MFC as present in Samsung Exynos 5422/5800 SoCs Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- arch/arm/mach-exynos/exynos.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c index c13d083..b343a1a 100644 --- a/arch/arm/mach-exynos/exynos.c +++ b/arch/arm/mach-exynos/exynos.c @@ -282,6 +282,7 @@ static void __init exynos_reserve(void) samsung,mfc-v5, samsung,mfc-v6, samsung,mfc-v7, + samsung,mfc-v8, }; for (i = 0; i ARRAY_SIZE(mfc_mem); i++) -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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: dts: Add dts file for odroid XU3 board
On Wed, 2014-12-03 at 11:53 -0800, Kevin Hilman wrote: Sjoerd Simons sjoerd.sim...@collabora.co.uk writes: Tried this on top of linux-next (next-20141125 and next20141203) and boots fine on my odroid-xu3. Thanks for doing this, I've been meaning to get a DTS upstream for this platform myself. I also noticed that the imprecise aborts I've been seeing when booting this board with the smdk5420 DTS are gone, so I don't have to dig into those now either. Thanks! :) For completeness, the problem with running the smdk5420 DTS on the XU3 is that the XU3 runs secure firmware while the SMD5420 doesn't.. Hence the imprecise aborts you were seeing. -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] ARM: dts: Add dts file for odroid XU3 board
On Tue, 2014-12-02 at 15:17 +0900, Heesub Shin wrote:
Hello Simons,
On 12/01/2014 09:59 PM, Sjoerd Simons wrote:
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+#include exynos5800.dtsi
Looking at exynos5800.dtsi, it derives from exynos5420.dtsi and seems
having differences on clock and mfc. Is it proper to include
exynos5800.dtsi here, instead of exynos5420.dtsi? It's just my curiosity
as I am not in a position to know detailed things on the soc. Only
semiconductor guys could answer this.
I would love to get a conclusive answer on this one as the exynos 5422
vs. exynos 5800 question seems to keep coming up (both on this list and
the u-boot one where XU3 support is being added as well).
As far as i understand things the Exynos 5800 is a variant of the
Exynos 5422 for chromebooks[0]. I suspect things are just being called
5800 in the kernel and u-boot as the chromebooks were the first boards
based on this SoC to reach mainline...
Which led to interesting things like:
#define EXYNOS5800_SOC_ID 0xE5422000
Iotw, the identifier for the 5800 is 0x5422, which doesn't really make
things more clear.
I'm working on the assumption that this SoC variation doesn't expose
differences to the OS. I did not yet test the MFC, but should get round
to that later this week, which should help in verifying the MFC side of
things at least.. I haven't yet seen any issues caused due to the
differences in clock setup between samsung,exynos5800-clock and
samsung,exynos5420-clock
+
+/ {
+ model = Hardkernel Odroid XU3;
+ compatible = hardkernel,odroid-xu3, samsung,exynos5800,
samsung,exynos5;
+
+ memory {
+ reg = 0x2000 0x8000;
+ };
Start address above should be 0x4000, not 0x2000.
Indeed, the Hardkernel DTS also starts at 0x4000, I missed that.
Looking at the other exynos5800/5420 based boards in the kernel they all
have their start offset at 0x2000, is this different for the XU3
because it runs with secure firmware or is there some other reason
behind this?
One more thing, having bootargs which specifies 'console=xxx' would be
better.
Hrm, i've got a dislike for chosen/bootargs as they typically seem
rather random/inconsistent (not sure who they're meant for). However, I
should indeed specify chosen/stdout-path to point to the serial console.
Thanks for your review!
0: See table at the bottom of
http://www.samsung.com/global/business/semiconductor/minisite/Exynos/w/solution.html#?v=octa_5422
--
Sjoerd Simons sjoerd.sim...@collabora.co.uk
Collabora Ltd.
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hey Marek, Inki, On Wed, 2014-11-19 at 12:15 +0100, Marek Szyprowski wrote: Hello Everyone, This is another attempt to finally make Exynos SYSMMU driver fully integrated with DMA-mapping subsystem. The main change from previous version is a rebase onto latest automatic DMA configuration for IOMMU masters patches from Will Deacon. Do you happen to know if anyone is working on iommu/dma-mapping patches for Exynos 5 based on this patchset? For some background to that question, We (re-)discovered yesterday that the out-of-tree exynos-reference kernel iommu patches are required to get HDMI out working on exynos 5 boards. The current situation in mainline is rather broken, HDMI output without CONFIG_DRM_EXYNOS_IOMMU results in just displaying stripes[0]. While turning on CONFIG_DRM_EXYNOS_IOMMU causes a kernel oops at boot 0: http://people.collabora.com/~sjoerd/14120001.jpg -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
[PATCH] ARM: dts: Add dts file for odroid XU3 board
Add DTS for the Hardkernel Odroid XU3. The name of the DTS file is kept the
same as the vendors naming, which means it's prefixed with exynos5422
instead of exynos5800 as the SoC name even though it includes the
exyno5800 dtsi.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 325 +
2 files changed, 326 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5422-odroidxu3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 38c89ca..0a898cc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -86,6 +86,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5420-arndale-octa.dtb \
exynos5420-peach-pit.dtb \
exynos5420-smdk5420.dtb \
+ exynos5422-odroidxu3.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb \
exynos5800-peach-pi.dtb
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
new file mode 100644
index 000..fe37004
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -0,0 +1,325 @@
+/*
+ * Hardkernel Odroid XU3 board device tree source
+ *
+ * Copyright (c) 2014 Collabora Ltd.
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+#include exynos5800.dtsi
+
+/ {
+ model = Hardkernel Odroid XU3;
+ compatible = hardkernel,odroid-xu3, samsung,exynos5800,
samsung,exynos5;
+
+ memory {
+ reg = 0x2000 0x8000;
+ };
+
+ fimd@1440 {
+ status = okay;
+ };
+
+ firmware@02073000 {
+ compatible = samsung,secure-firmware;
+ reg = 0x02073000 0x1000;
+ };
+
+ fixed-rate-clocks {
+ oscclk {
+ compatible = samsung,exynos5420-oscclk;
+ clock-frequency = 2400;
+ };
+ };
+
+ hsi2c_4: i2c@12CA {
+ status = okay;
+
+ s2mps11_pmic@66 {
+ compatible = samsung,s2mps11-pmic;
+ reg = 0x66;
+ s2mps11,buck2-ramp-delay = 12;
+ s2mps11,buck34-ramp-delay = 12;
+ s2mps11,buck16-ramp-delay = 12;
+ s2mps11,buck6-ramp-enable = 1;
+ s2mps11,buck2-ramp-enable = 1;
+ s2mps11,buck3-ramp-enable = 1;
+ s2mps11,buck4-ramp-enable = 1;
+
+ s2mps11_osc: clocks {
+ #clock-cells = 1;
+ clock-output-names = s2mps11_ap,
+ s2mps11_cp, s2mps11_bt;
+ };
+
+ regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = vdd_ldo1;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ regulator-always-on;
+ };
+
+ ldo3_reg: LDO3 {
+ regulator-name = vdd_ldo3;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ };
+
+ ldo5_reg: LDO5 {
+ regulator-name = vdd_ldo5;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ };
+
+ ldo6_reg: LDO6 {
+ regulator-name = vdd_ldo6;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ regulator-always-on;
+ };
+
+ ldo7_reg: LDO7 {
+ regulator-name = vdd_ldo7;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always
[PATCH] ARM: exynos_defconfig: Enable CONFIG_FHANDLE
CONFIG_FHANDLE is required by systemd, which is the default init system in more and more distributions. So lets enable it for Exynos as well (it's already enabled in multi_v7_defconfig) Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index e419fac..d4751ef 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -1,4 +1,5 @@ CONFIG_SYSVIPC=y +CONFIG_FHANDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_CGROUPS=y -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: fix infinite loop issue incurred by no pair
On Tue, 2014-11-18 at 12:20 +0900, Inki Dae wrote:
This patch makes the deferred probe is tried up to 3 times in maximum.
However, this is considered only for Exynos drm so I think other SoC
drivers could also produce same issue. Therefore, the best way to resolve
this issue, infinite loop incurred by defered probe, would be that dd core
is fixed up corrrectly.
At first sight this seems to make little to no sense. Unless i'm
mistaken this would cause the exynos drm probe return -ENODEV to the dd
core, causing it to stop trying to probe. Which obviously breaks your
infinite loop, it also breaks situations where the probe needs to be
retried more then 3 times.
I suspect with this patch once exynos DRM is loaded and actually validly
needs to defer (iotw when the required modules do exist but simply
aren't loaded just yet), it still jumps into an infinite loop which you
break after 3 tries after which the display will simply never come up
even if everything is in place because the core doesn't know it should
re-probe
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index eab12f0..4d84f3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -38,6 +38,8 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
+#define MAX_TRY_PROBE_DEFER 3
+
static struct platform_device *exynos_drm_pdev;
static DEFINE_MUTEX(drm_component_lock);
@@ -481,6 +483,7 @@ static struct component_match
*exynos_drm_match_add(struct device *dev)
struct component_match *match = NULL;
struct component_dev *cdev;
unsigned int attach_cnt = 0;
+ static unsigned int try_probe_defer;
mutex_lock(drm_component_lock);
@@ -527,6 +530,11 @@ out_lock:
mutex_unlock(drm_component_lock);
+ if (++try_probe_defer MAX_TRY_PROBE_DEFER) {
+ try_probe_defer = 0;
+ return ERR_PTR(-ENODEV);
+ }
+
return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
}
smime.p7s
Description: S/MIME cryptographic signature
[PATCH] ARM: dts: Explicitly set dr_mode on exynos5250-snow
Explicitly set the dr_mode for the dwc3 controller on the
Snow board to host mode. This is required to ensure the
controller is initialized in the right mode if the kernel is
build with USB gadget support.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
arch/arm/boot/dts/exynos5250-snow.dts | 4
arch/arm/boot/dts/exynos5250.dtsi | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index e51fcef..60429ad 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -624,4 +624,8 @@
num-cs = 1;
};
+usbdrd_dwc3 {
+ dr_mode = host;
+};
+
#include cros-ec-keyboard.dtsi
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index f21b9aa..d55c1a2 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -555,7 +555,7 @@
#size-cells = 1;
ranges;
- dwc3 {
+ usbdrd_dwc3: dwc3 {
compatible = synopsys,dwc3;
reg = 0x1200 0x1;
interrupts = 0 72 0;
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: resolve infinite loop issue on non multi-platform
On Thu, 2014-11-06 at 23:10 +0900, Inki Dae wrote:
This patch resovles the infinite loop issue incurred
when Exyno drm driver is enabled but all kms drivers
are disabled on Exynos board by returning -EPROBE_DEFER
only in case that there is kms device registered.
It would be nice if you could explain in the commit message/comment why
returning -EPROBE_DEFER causes an infinite loop and why it's the wrong
thing to do in this case?
Even if you know this probe will never succeed in the future (so
deferring is actually pointless), deferring really shouldn't trigger
infinte loops in calling code
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index ecc86aa..14c6af7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -488,6 +488,12 @@ static struct component_match
*exynos_drm_match_add(struct device *dev)
mutex_lock(drm_component_lock);
+ /* Do not retry to probe if there is no any kms driver regitered. */
+ if (list_empty(drm_component_list)) {
+ mutex_unlock(drm_component_lock);
+ return ERR_PTR(-ENODEV);
+ }
+
list_for_each_entry(cdev, drm_component_list, list) {
/*
* Add components to master only in case that crtc and
smime.p7s
Description: S/MIME cryptographic signature
Re: [GIT PULL 2/2] Samsung defconfig updates for v3.18
On Tue, 2014-10-14 at 23:32 -0700, Olof Johansson wrote: On Tue, Oct 14, 2014 at 4:27 PM, Kukjin Kim kgene@samsung.com wrote: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-defconfig for you to fetch changes up to 508423bebcda29eb0ba7c627f895387dad7cdcd6: ARM: exynos_defconfig: enable USB gadget support (2014-09-25 18:20:18 +0900) Merged, thanks. Hrm, enabling USB gadget support will actually regress USB on Exynos peach boards and Arndale Octa without some of the DT fixes that landed in armsoc next/late branch. Specifically: 5c42acdb9bab595482b966b22ab5e2f6f359 dbb62ef9ade6e92737d3fac199665b8b7c455959 Might be good to cherry-pick those into for-next at this point (they're rather trivial) -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
[PATCH 2/3] ARM: dts: exynos: Explicitly set dr_mode on arndale-octa
Explicitly set the dr_mode for the second dwc3 controller on the
Arndale Octa board to host mode. This is required to ensure the
controller is initialized in the right mode if the kernel is build with
USB gadget support
Reported-By: Andreas Färber afaer...@suse.de
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
Changes in v3: new patch
Changes in v4: Rebased on linux-samsung for-next
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 70a559c..7508099 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -367,3 +367,7 @@
};
};
};
+
+usbdrd_dwc3_1 {
+ dr_mode = host;
+};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: exynos_defconfig: enable USB gadget support
Enable USB gadget support without support for any specific gadgets to more easily catch cases where a devices dts doesn't specify the usb controllers dr_mode while it should. Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- Changes in v4: Rebased on linux-samsung for-next arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index b14d8c3..2cf22bb 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -54,6 +54,7 @@ CONFIG_SMSC911X=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y +CONFIG_USB_GADGET=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y CONFIG_KEYBOARD_CROS_EC=y -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3 v4] Fix Exynos USB on kernels with USB Gadget support
Same patches as v3 but rebased on https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next When building a kernel with support for both USB host and USB Gadget support on the dwc3 controller on the Exynos5 soc will go into USB OTG mode unless otherwise specified in the dtb, which is unhelpful for boards hooked up to run as USB host. First patch in this set explicitely set the dual-role mode for the dwc3 controller on Peach pi and Peach pit boards to host mode. Second patch adds similar updates for Arndale Octa as reported by Andreas Färber. Last patch enables gadget mode in the default exynos config to more easily catch/trigger issues like these. I suspect the Samsung SMDK5420 DTS might need similar changes, so it would be great if users of those board could verify this. Changes in v2: alphabetically sort the dts entries Changes in v3: Add DTS updates for arndale octa Changes in v4: Rebased on todays linux-samsungs for-next branch Sjoerd Simons (3): ARM: dts: exynos: Explicitly set dr_mode on peach-pit and peach-pi ARM: dts: exynos: Explicitly set dr_mode on arndale-octa ARM: exynos_defconfig: enable USB gadget support arch/arm/boot/dts/exynos5420-arndale-octa.dts | 4 arch/arm/boot/dts/exynos5420-peach-pit.dts| 8 arch/arm/boot/dts/exynos5420.dtsi | 4 ++-- arch/arm/boot/dts/exynos5800-peach-pi.dts | 8 arch/arm/configs/exynos_defconfig | 1 + 5 files changed, 23 insertions(+), 2 deletions(-) -- 2.1.0 Sjoerd Simons (3): ARM: dts: exynos: Explicitly set dr_mode on peach-pit and peach-pi ARM: dts: exynos: Explicitly set dr_mode on arndale-octa ARM: exynos_defconfig: enable USB gadget support arch/arm/boot/dts/exynos5420-arndale-octa.dts | 4 arch/arm/boot/dts/exynos5420-peach-pit.dts| 8 arch/arm/boot/dts/exynos5420.dtsi | 4 ++-- arch/arm/boot/dts/exynos5800-peach-pi.dts | 8 arch/arm/configs/exynos_defconfig | 1 + 5 files changed, 23 insertions(+), 2 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3 v4] ARM: dts: exynos: Explicitly set dr_mode on peach-pit and peach-pi
In case the optional dr_mode property isn't set in the dwc3 nodes the
the controller will go into OTG mode iff both USB host and USB gadget
functionality are enabled in the kernel configuration. Unfortunately this
results in USB not working on exynos5420-peach-pit and
exynos5800-peach-pi with such a kernel configuration unless manually
change the mode. To resolve that explicitly configure the dual role
mode as host
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Reviewed-by: Andreas Färber afaer...@suse.de
---
Changes in v2: alphabetically sort the dts entries
Changes in v3: Fix typo in commit message
Changes in v4: Rebased on linux-samsung for-next
arch/arm/boot/dts/exynos5420-peach-pit.dts | 8
arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
arch/arm/boot/dts/exynos5800-peach-pi.dts | 8
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 17dae508..9a050e1 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -841,6 +841,14 @@
status = okay;
};
+usbdrd_dwc3_0 {
+ dr_mode = host;
+};
+
+usbdrd_dwc3_1 {
+ dr_mode = host;
+};
+
usbdrd_phy0 {
vbus-supply = usb300_vbus_reg;
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index bfe056d..8617a03 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -815,7 +815,7 @@
#size-cells = 1;
ranges;
- dwc3 {
+ usbdrd_dwc3_0: dwc3 {
compatible = snps,dwc3;
reg = 0x1200 0x1;
interrupts = 0 72 0;
@@ -841,7 +841,7 @@
#size-cells = 1;
ranges;
- dwc3 {
+ usbdrd_dwc3_1: dwc3 {
compatible = snps,dwc3;
reg = 0x1240 0x1;
interrupts = 0 73 0;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 4d1492e..e8fdda8 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -829,6 +829,14 @@
status = okay;
};
+usbdrd_dwc3_0 {
+ dr_mode = host;
+};
+
+usbdrd_dwc3_1 {
+ dr_mode = host;
+};
+
usbdrd_phy0 {
vbus-supply = usb300_vbus_reg;
};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] s5p-mfc: Use decode status instead of display status on MFCv5
Hey Kamil, On Tue, 2014-09-23 at 15:58 +0200, Kamil Debski wrote: Commit 90c0ae50097 changed how the frame_type of a decoded frame gets determined, by switching from the get_dec_frame_type to get_disp_frame_type operation. Unfortunately it seems that on MFC v5 the result of get_disp_frame_type is always 0 (no display) when decoding (tested with H264), resulting in no frame ever being output from the decoder. Could you tell me which firmware version do you use (date)? I'm using the firmware version as included in http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/ Unfortunately there is no specific version information included about the firmware. The commit that added it is fb5cda9c70277f6 dated Nov 28 17:43:06 2012 +0530, so that at least gives some information about the time-frame. -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
[PATCH] [media] s5p-mfc: Use decode status instead of display status on MFCv5
Commit 90c0ae50097 changed how the frame_type of a decoded frame
gets determined, by switching from the get_dec_frame_type to
get_disp_frame_type operation. Unfortunately it seems that on MFC v5 the
result of get_disp_frame_type is always 0 (no display) when decoding
(tested with H264), resulting in no frame ever being output from the
decoder.
This patch reverts MFC v5 to the previous behaviour while keeping the
new behaviour for v6 and up.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index d35b041..27ca9d0 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -264,7 +264,12 @@ static void s5p_mfc_handle_frame_new(struct s5p_mfc_ctx
*ctx, unsigned int err)
unsigned int frame_type;
dspl_y_addr = s5p_mfc_hw_call(dev-mfc_ops, get_dspl_y_adr, dev);
- frame_type = s5p_mfc_hw_call(dev-mfc_ops, get_disp_frame_type, ctx);
+ if (IS_MFCV6_PLUS(dev))
+ frame_type = s5p_mfc_hw_call(dev-mfc_ops,
+ get_disp_frame_type, ctx);
+ else
+ frame_type = s5p_mfc_hw_call(dev-mfc_ops,
+ get_dec_frame_type, dev);
/* If frame is same as previous then skip and do not dequeue */
if (frame_type == S5P_FIMV_DECODE_FRAME_SKIPPED) {
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/3 v3] Fix Exynos USB on kernels with USB Gadget support
Hey Kukjin, It's been almost a month since I posted the first iteration of this patchset on the list, with only trivial cosmetic changes and an addition of a similar fix for Arndale Octa boards. Do you feel it needs more review from specific folks before pulling it in or ? Seems a bit of a shame if this would fail to make it for 3.18 (one could even argue the dt patches are 3.17 RC material!) as it fixes USB functionality being broken depending on the kernel configuration used. On Mon, 2014-09-15 at 12:52 +0200, Sjoerd Simons wrote: When building a kernel with support for both USB host and USB Gadget support on the dwc3 controller on the Exynos5 soc will go into USB OTG mode unless otherwise specified in the dtb, which is unhelpful for boards hooked up to run as USB host. First patch in this set explicitely set the dual-role mode for the dwc3 controller on Peach pi and Peach pit boards to host mode. Second patch adds similar updates for Arndale Octa as reported by Andreas Färber. Last patch enables gadget mode in the default exynos config to more easily catch/trigger issues like these. I suspect the Samsung SMDK5420 DTS might need similar changes, so it would be great if users of those board could verify this. Changes in v2: alphabetically sort the dts entries Changes in v3: Add DTS updates for arndale octa Sjoerd Simons (3): ARM: dts: exynos: Explicitly set dr_mode on peach-pit and peach-pi ARM: dts: exynos: Explicitly set dr_mode on arndale-octa ARM: exynos_defconfig: enable USB gadget support arch/arm/boot/dts/exynos5420-arndale-octa.dts | 4 arch/arm/boot/dts/exynos5420-peach-pit.dts| 8 arch/arm/boot/dts/exynos5420.dtsi | 4 ++-- arch/arm/boot/dts/exynos5800-peach-pi.dts | 8 arch/arm/configs/exynos_defconfig | 1 + 5 files changed, 23 insertions(+), 2 deletions(-) smime.p7s Description: S/MIME cryptographic signature
[PATCH 0/2 v2] Add OF match tables for the ChromeOs EC subdevices
[ This is essentially a resend, adding Javiers reviewed-by and fixing some small identation issues in the second patch. Also added Wolfgang and Dimitry in the to, as i missed them last time ] The ChromeOS EC MFD driver registers its sub-devices with both a (platform) name and an OF compatibility string. As a result of this the modalias passed on to user-space will be based on the OF compatibility string. Thus to be able to rely on autoloading in case the subdevices are build as modules they need to export the necessary module aliases based to match the of information. The two patches in these series add the requird of match information to the EC subdevices I guess the first patch should through the i2c tree while the second one would be for the input tree? Sjoerd Simons (2): i2c: cros-ec-tunnel: Add of match table input: cros_ec_keyb: Add of match table drivers/i2c/busses/i2c-cros-ec-tunnel.c | 9 + drivers/input/keyboard/cros_ec_keyb.c | 9 + 2 files changed, 18 insertions(+) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] input: cros_ec_keyb: Add of match table
To enable the cros_ec_keyb driver to be auto-loaded when build as
module add an of match table (and export it) to match the modalias
information passed on to userspace as the Cros EC MFD driver registers
the MFD subdevices with an of_compatibility string.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes in v2: Fixed some indentation issues
drivers/input/keyboard/cros_ec_keyb.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 791781a..e1903ec 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -342,10 +342,19 @@ static int cros_ec_keyb_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(cros_ec_keyb_pm_ops, NULL, cros_ec_keyb_resume);
+#ifdef CONFIG_OF
+static const struct of_device_id cros_ec_keyb_of_match[] = {
+ { .compatible = google,cros-ec-keyb },
+ {},
+};
+MODULE_DEVICE_TABLE(of, cros_ec_keyb_of_match);
+#endif
+
static struct platform_driver cros_ec_keyb_driver = {
.probe = cros_ec_keyb_probe,
.driver = {
.name = cros-ec-keyb,
+ .of_match_table = of_match_ptr(cros_ec_keyb_of_match),
.pm = cros_ec_keyb_pm_ops,
},
};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 v2] i2c: cros-ec-tunnel: Add of match table
To enable the cros-ec-tunnel driver to be auto-loaded when build as a
module add an of match table (and export it) to match the modalias
information passed on to userspace as the Cros EC MFD driver registers
the MFD subdevices with an of_compatibility string.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes in v2: none
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index 05e033c..0403ec1 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -310,11 +310,20 @@ static int ec_i2c_remove(struct platform_device *dev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id cros_ec_i2c_of_match[] = {
+ { .compatible = google,cros-ec-i2c-tunnel },
+ {},
+};
+MODULE_DEVICE_TABLE(of, cros_ec_i2c_of_match);
+#endif
+
static struct platform_driver ec_i2c_tunnel_driver = {
.probe = ec_i2c_probe,
.remove = ec_i2c_remove,
.driver = {
.name = cros-ec-i2c-tunnel,
+ .of_match_table = of_match_ptr(cros_ec_i2c_of_match),
},
};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3 v3] ARM: dts: exynos: Explicitly set dr_mode on peach-pit and peach-pi
In case the optional dr_mode property isn't set in the dwc3 nodes the
the controller will go into OTG mode iff both USB host and USB gadget
functionality are enabled in the kernel configuration. Unfortunately this
results in USB not working on exynos5420-peach-pit and
exynos5800-peach-pi with such a kernel configuration unless manually
change the mode. To resolve that explicitly configure the dual role
mode as host
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Reviewed-by: Andreas Färber afaer...@suse.de
---
Changes in v2: alphabetically sort the dts entries
Changes in v3: Fix typo in commit message
arch/arm/boot/dts/exynos5420-peach-pit.dts | 8
arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
arch/arm/boot/dts/exynos5800-peach-pi.dts | 8
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 228a6b1..29d3a59 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -427,6 +427,14 @@
status = okay;
};
+usbdrd_dwc3_0 {
+ dr_mode = host;
+};
+
+usbdrd_dwc3_1 {
+ dr_mode = host;
+};
+
usbdrd_phy0 {
vbus-supply = usb300_vbus_reg;
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index bfe056d..8617a03 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -815,7 +815,7 @@
#size-cells = 1;
ranges;
- dwc3 {
+ usbdrd_dwc3_0: dwc3 {
compatible = snps,dwc3;
reg = 0x1200 0x1;
interrupts = 0 72 0;
@@ -841,7 +841,7 @@
#size-cells = 1;
ranges;
- dwc3 {
+ usbdrd_dwc3_1: dwc3 {
compatible = snps,dwc3;
reg = 0x1240 0x1;
interrupts = 0 73 0;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index f3ee48b..2064550 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -425,6 +425,14 @@
status = okay;
};
+usbdrd_dwc3_0 {
+ dr_mode = host;
+};
+
+usbdrd_dwc3_1 {
+ dr_mode = host;
+};
+
usbdrd_phy0 {
vbus-supply = usb300_vbus_reg;
};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3 v3] Fix Exynos USB on kernels with USB Gadget support
When building a kernel with support for both USB host and USB Gadget support on the dwc3 controller on the Exynos5 soc will go into USB OTG mode unless otherwise specified in the dtb, which is unhelpful for boards hooked up to run as USB host. First patch in this set explicitely set the dual-role mode for the dwc3 controller on Peach pi and Peach pit boards to host mode. Second patch adds similar updates for Arndale Octa as reported by Andreas Färber. Last patch enables gadget mode in the default exynos config to more easily catch/trigger issues like these. I suspect the Samsung SMDK5420 DTS might need similar changes, so it would be great if users of those board could verify this. Changes in v2: alphabetically sort the dts entries Changes in v3: Add DTS updates for arndale octa Sjoerd Simons (3): ARM: dts: exynos: Explicitly set dr_mode on peach-pit and peach-pi ARM: dts: exynos: Explicitly set dr_mode on arndale-octa ARM: exynos_defconfig: enable USB gadget support arch/arm/boot/dts/exynos5420-arndale-octa.dts | 4 arch/arm/boot/dts/exynos5420-peach-pit.dts| 8 arch/arm/boot/dts/exynos5420.dtsi | 4 ++-- arch/arm/boot/dts/exynos5800-peach-pi.dts | 8 arch/arm/configs/exynos_defconfig | 1 + 5 files changed, 23 insertions(+), 2 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 v3] ARM: dts: exynos: Explicitly set dr_mode on arndale-octa
Explicitly set the dr_mode for the second dwc3 controller on the
Arndale Octa board to host mode. This is required to ensure the
controller is initialized in the right mode if the kernel is build with
USB gadget support
Reported-By: Andreas Färber afaer...@suse.de
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
Changes in v3: new patch
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 434fd9d..fc2e983 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -375,3 +375,7 @@
};
};
};
+
+usbdrd_dwc3_1 {
+ dr_mode = host;
+};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3 v3] ARM: exynos_defconfig: enable USB gadget support
Enable USB gadget support without support for any specific gadgets to more easily catch cases where a devices dts doesn't specify the usb controllers dr_mode while it should. Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index fc7d168..3664120 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -54,6 +54,7 @@ CONFIG_SMSC911X=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y +CONFIG_USB_GADGET=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y CONFIG_KEYBOARD_CROS_EC=y -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Input: atmel_mxt_ts: Add of node type to the i2c table
Hey Lee,
On Wed, 2014-09-10 at 10:28 +0100, Lee Jones wrote:
On Tue, 09 Sep 2014, Javier Martinez Canillas wrote:
[adding Lee Jones to cc list since I'm referring on a series he posted]
Hello Sjoerd,
On 09/09/2014 09:52 AM, Sjoerd Simons wrote:
For i2c devices in OF the modalias exposed to userspace is i2c:node
type, for the Maxtouch driver this is i2c:maxtouch.
Add maxtouch to the i2c id table such that userspace can correctly
load the module for the device and drop the OF table as it's not
needed for i2c devices.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/input/touchscreen/atmel_mxt_ts.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index db178ed..57ff26d 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -2267,16 +2267,11 @@ static int mxt_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(mxt_pm_ops, mxt_suspend, mxt_resume);
-static const struct of_device_id mxt_of_match[] = {
- { .compatible = atmel,maxtouch, },
- {},
-};
-MODULE_DEVICE_TABLE(of, mxt_of_match);
-
static const struct i2c_device_id mxt_id[] = {
{ qt602240_ts, 0 },
{ atmel_mxt_ts, 0 },
{ atmel_mxt_tp, 0 },
+ { maxtouch, 0 },
{ mXT224, 0 },
{ }
};
@@ -2286,7 +2281,6 @@ static struct i2c_driver mxt_driver = {
.driver = {
.name = atmel_mxt_ts,
.owner = THIS_MODULE,
- .of_match_table = of_match_ptr(mxt_of_match),
.pm = mxt_pm_ops,
},
.probe = mxt_probe,
I see that Lee is working to allow the I2C subsystem to not need an I2C ID
table to match [0]. I'll let Lee to comment what the future plans are and if
his series are going to solve your issue since I'm not that familiar with
the
I2C core.
It's wrong to expect DT to probe these devices without a compatible
string. It does so at the moment, but this is a bi-product and not
the correct method.
Ok, which means removing the mxt_of_match table in this patch is wrong..
I'll fix that for for a V2.
However that makes adding the maxtouch string to the i2c device table
somewhat cumbersome as it only gets added in this case to ensure
module-autoloading can happen as the modalias presented to userspace is
going still going to be i2c:maxtouch.
Tbh, the bigger problem this is pointing out is that for I2C devices
with only an OF compability tring module auto-loading is broken...
--
Sjoerd Simons sjoerd.sim...@collabora.co.uk
Collabora Ltd.
smime.p7s
Description: S/MIME cryptographic signature
[PATCH] Input: atmel_mxt_ts: Add of node type to the i2c table
For i2c devices in OF the modalias exposed to userspace is i2c:node
type, for the Maxtouch driver this is i2c:maxtouch.
Add maxtouch to the i2c id table such that userspace can correctly
load the module for the device and drop the OF table as it's not
needed for i2c devices.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/input/touchscreen/atmel_mxt_ts.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index db178ed..57ff26d 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -2267,16 +2267,11 @@ static int mxt_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(mxt_pm_ops, mxt_suspend, mxt_resume);
-static const struct of_device_id mxt_of_match[] = {
- { .compatible = atmel,maxtouch, },
- {},
-};
-MODULE_DEVICE_TABLE(of, mxt_of_match);
-
static const struct i2c_device_id mxt_id[] = {
{ qt602240_ts, 0 },
{ atmel_mxt_ts, 0 },
{ atmel_mxt_tp, 0 },
+ { maxtouch, 0 },
{ mXT224, 0 },
{ }
};
@@ -2286,7 +2281,6 @@ static struct i2c_driver mxt_driver = {
.driver = {
.name = atmel_mxt_ts,
.owner = THIS_MODULE,
- .of_match_table = of_match_ptr(mxt_of_match),
.pm = mxt_pm_ops,
},
.probe = mxt_probe,
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Input: atmel_mxt_ts: Add of node type to the i2c table
On Tue, 2014-09-09 at 11:29 +0100, Nick Dyer wrote: On 09/09/14 11:21, Javier Martinez Canillas wrote: On 09/09/2014 09:52 AM, Sjoerd Simons wrote: For i2c devices in OF the modalias exposed to userspace is i2c:node type, for the Maxtouch driver this is i2c:maxtouch. Add maxtouch to the i2c id table such that userspace can correctly load the module for the device and drop the OF table as it's not needed for i2c devices. I see that Lee is working to allow the I2C subsystem to not need an I2C ID table to match [0]. I'll let Lee to comment what the future plans are and if his series are going to solve your issue since I'm not that familiar with the I2C core. I can see the benefit of not having the duplication. Am I correct that you're saying that it might make more sense to remove the i2c ids rather than the OF table, if Lee's changes are accepted? You would still need the i2C table for non-OF platforms ofcourse. I'm not sure what happens with the modalias as exposed to userspace with Lee's patchset, if that gets changed to prefer an of: type instead of the current i2c: prefixed ones this patch (at that point) isn't needed. -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 2/2 v2] ARM: exynos_defconfig: enable USB gadget support
On Wed, 2014-08-27 at 03:38 +0200, Andreas Färber wrote: Am 26.08.2014 09:30, schrieb Sjoerd Simons: Enable USB gadget support without support for any specific gadgets to more easily catch cases where a devices dts doesn't specify the usb controllers dr_mode while it should. Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- Changes in v2: none arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index fc7d168..3664120 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -54,6 +54,7 @@ CONFIG_SMSC911X=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y +CONFIG_USB_GADGET=y Do we also need CONFIG_USB_DWC3_DUAL_ROLE=y? The default seemed to be CONFIG_USB_DWC3_HOST. Nope that gets set by this Kconfig snippet: choice bool DWC3 Mode Selection default USB_DWC3_DUAL_ROLE if (USB USB_GADGET) default USB_DWC3_HOST if (USB !USB_GADGET) default USB_DWC3_GADGET if (!USB USB_GADGET) Iotw by both enable USB and USB_GADGET the default will switch form CONFIG_USB_DWC3_HOST to CONFIG_USB_DWC3_DUAL_ROLE=y -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 0/2 v2] Fix Exynos peach USB on kernels with USB Gadget support
On Wed, 2014-08-27 at 04:08 +0200, Andreas Färber wrote: Hi, Am 26.08.2014 09:30, schrieb Sjoerd Simons: I suspect other boards base using exynos5420/5800 might need the similar fixes (Arndale Octa and Samsung SMDK5420) to their dts files, so would be great if folks with those board could verify this. usbdrd_dwc3_1 is indeed required for the Arndale Octa. Not sure about 0. I tested my attaching a USB 3.0 disk - is there an easier way to tell? That seems to be the easiest way to tell. In my testing when things broke no USB host functionality would work, so USB 3 isn't a requirement. You can also build with USB_DWC3_DEBUG enabled and check the mode file it generates in debugfs to see set the controller mode to see how it gets setup by default and change the mode without rebuilding the dts. From looking at the board on the arndaleboard wiki[0], it looks like it has one USB 3 host (which i guess is usbdrd_dwc3_1?) and a USB 2 OTG port which might be usbdrd_dwc3_0 (in which case the default setting for otg is correct). 0: http://www.arndaleboard.org/wiki/index.php/O_WiKi#Detail_of_Arndale_Board -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
[PATCH 0/2 v2] Fix Exynos peach USB on kernels with USB Gadget support
When building a kernel with support for both USB host and USB Gadget support on the dwc3 controller on the Exynos5 soc will go into USB OTG mode unless otherwise specified in the dtb, which is unhelpful for boards hooked up to run as USB host. First patch in this set explicitely set the dual-role mode for the dwc3 controller on Peach pi and Peach pit boards to host mode. Second patch enables gadget mode in the default exynos config to more easily catch/trigger issues like these. I suspect other boards base using exynos5420/5800 might need the similar fixes (Arndale Octa and Samsung SMDK5420) to their dts files, so would be great if folks with those board could verify this. Changes in v2: alphabetically sort the dts entries Sjoerd Simons (2): ARM: dts: exynos: Explicitly set dr_mode on peach-pit and peach-pi ARM: exynos_defconfig: enable USB gadget support arch/arm/boot/dts/exynos5420-peach-pit.dts | 8 arch/arm/boot/dts/exynos5420.dtsi | 4 ++-- arch/arm/boot/dts/exynos5800-peach-pi.dts | 8 arch/arm/configs/exynos_defconfig | 1 + 4 files changed, 19 insertions(+), 2 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 v2] ARM: exynos_defconfig: enable USB gadget support
Enable USB gadget support without support for any specific gadgets to more easily catch cases where a devices dts doesn't specify the usb controllers dr_mode while it should. Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- Changes in v2: none arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index fc7d168..3664120 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -54,6 +54,7 @@ CONFIG_SMSC911X=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y +CONFIG_USB_GADGET=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y CONFIG_KEYBOARD_CROS_EC=y -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 v2] ARM: dts: exynos: Explicitly set dr_mode on peach-pit and peach-pi
In case the optional dr_mode property isn't set in the dwc3 nodes the
the controller will go into OTG mode iff both USB host and USB gadget
functionality are enabled in the kernel configuration. Unfortunately this
results in USB not working on exynos5420-peach-pit and
exynos5800-peach-pi with such a kernel configuration unless manually
change the mode. To resolve that explicitely configure the dual role
mode as host
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
Changes in v2: alphabetically sort the dts entries
arch/arm/boot/dts/exynos5420-peach-pit.dts | 8
arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
arch/arm/boot/dts/exynos5800-peach-pi.dts | 8
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 228a6b1..29d3a59 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -427,6 +427,14 @@
status = okay;
};
+usbdrd_dwc3_0 {
+ dr_mode = host;
+};
+
+usbdrd_dwc3_1 {
+ dr_mode = host;
+};
+
usbdrd_phy0 {
vbus-supply = usb300_vbus_reg;
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index bfe056d..8617a03 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -815,7 +815,7 @@
#size-cells = 1;
ranges;
- dwc3 {
+ usbdrd_dwc3_0: dwc3 {
compatible = snps,dwc3;
reg = 0x1200 0x1;
interrupts = 0 72 0;
@@ -841,7 +841,7 @@
#size-cells = 1;
ranges;
- dwc3 {
+ usbdrd_dwc3_1: dwc3 {
compatible = snps,dwc3;
reg = 0x1240 0x1;
interrupts = 0 73 0;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index f3ee48b..2064550 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -425,6 +425,14 @@
status = okay;
};
+usbdrd_dwc3_0 {
+ dr_mode = host;
+};
+
+usbdrd_dwc3_1 {
+ dr_mode = host;
+};
+
usbdrd_phy0 {
vbus-supply = usb300_vbus_reg;
};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] i2c: cros-ec-tunnel: Add of match table
To enable the cros-ec-tunnel driver to be auto-loaded when build as a
module add an of match table (and export it) to match the modalias
information passed on to userspace as the Cros EC MFD driver registers
the MFD subdevices with an of_compatibility string.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes in v2: Fix stray newline and indentation issues
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index 05e033c..0403ec1 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -310,11 +310,20 @@ static int ec_i2c_remove(struct platform_device *dev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id cros_ec_i2c_of_match[] = {
+ { .compatible = google,cros-ec-i2c-tunnel },
+ {},
+};
+MODULE_DEVICE_TABLE(of, cros_ec_i2c_of_match);
+#endif
+
static struct platform_driver ec_i2c_tunnel_driver = {
.probe = ec_i2c_probe,
.remove = ec_i2c_remove,
.driver = {
.name = cros-ec-i2c-tunnel,
+ .of_match_table = of_match_ptr(cros_ec_i2c_of_match),
},
};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 v2] input: cros_ec_keyb: Add of match table
To enable the cros_ec_keyb driver to be auto-loaded when build as
module add an of match table (and export it) to match the modalias
information passed on to userspace as the Cros EC MFD driver registers
the MFD subdevices with an of_compatibility string.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes in v2: none
drivers/input/keyboard/cros_ec_keyb.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 791781a..e1903ec 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -342,10 +342,19 @@ static int cros_ec_keyb_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(cros_ec_keyb_pm_ops, NULL, cros_ec_keyb_resume);
+#ifdef CONFIG_OF
+static const struct of_device_id cros_ec_keyb_of_match[] = {
+ { .compatible = google,cros-ec-keyb },
+ {},
+};
+MODULE_DEVICE_TABLE(of, cros_ec_keyb_of_match);
+#endif
+
static struct platform_driver cros_ec_keyb_driver = {
.probe = cros_ec_keyb_probe,
.driver = {
.name = cros-ec-keyb,
+ .of_match_table = of_match_ptr(cros_ec_keyb_of_match),
.pm = cros_ec_keyb_pm_ops,
},
};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2 v2] Add of match tables for the ChromeOs EC subdevices
The ChromeOS EC MFD driver registers its sub-devices with both a (platform) name and an of compatibility string. As a result of this the modalias passed on to user-space will be based on the of compatibility string. Thus to be able to rely on autoloading in case the subdevices are build as modules they need to export the necessary module aliases based to match the of information. The two patches in these series add the requird of match information to the EC subdevices Changes in v2: Fix stray newline and indentation issues in the first patch Sjoerd Simons (2): i2c: cros-ec-tunnel: Add of match table input: cros_ec_keyb: Add of match table drivers/i2c/busses/i2c-cros-ec-tunnel.c | 9 + drivers/input/keyboard/cros_ec_keyb.c | 9 + 2 files changed, 18 insertions(+) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] input: cros_ec_keyb: Add of match table
Hey,
On Sat, 2014-08-23 at 17:42 +0400, Sergei Shtylyov wrote:
Hello.
On 8/23/2014 3:03 AM, Sjoerd Simons wrote:
To enable the cros_ec_keyb driver to be auto-loaded when build as
module add an of match table (and export it) to match the modalias
information passed on to userspace as the Cros EC MFD driver registers
the MFD subdevices with an of_compatibility string.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/input/keyboard/cros_ec_keyb.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 791781a..0bdbf2d 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -342,10 +342,20 @@ static int cros_ec_keyb_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(cros_ec_keyb_pm_ops, NULL, cros_ec_keyb_resume);
+#ifdef CONFIG_OF
+static const struct of_device_id cros_ec_keyb_of_match[] = {
Perhaps better to use '__maybe_unused' instead of #ifdef...
Hmm, looks like the rtc-ds1742.c driver is the only one in the kernel
tree using that strategy, while all others use #ifdef CONFIG_OF. So i'm
inclined to keep the #ifdef here, ooi what is your rationale behind
suggesting __maybe_unused?
+ { .compatible = google,cros-ec-keyb },
+ {},
+};
+MODULE_DEVICE_TABLE(of, cros_ec_keyb_of_match);
+#endif
+
+
Too many empty lines.
static struct platform_driver cros_ec_keyb_driver = {
.probe = cros_ec_keyb_probe,
.driver = {
.name = cros-ec-keyb,
+ .of_match_table = of_match_ptr (cros_ec_keyb_of_match),
There shouldn't be space before (.
Will fix the identation issues in a v2.
Thanks for the review,
Sjoerd
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hey, On Fri, 2014-08-22 at 16:54 -0700, Kevin Hilman wrote: Tomasz Figa tomasz.f...@gmail.com writes: Kukjin, On 31.07.2014 20:32, Kukjin Kim wrote: On 07/30/14 17:07, Thomas Abraham wrote: The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver. Suggested-by: Tomasz Figat.f...@samsung.com Cc: Kukjin Kimkgene@samsung.com Looks good to me, Acked-by: Kukjin Kim kgene@samsung.com BTW, who will handle this series? I hope see this series in 3.17. This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree. So has this series been picked up anywhere? I don't see it in your samsung-clk tree, nor in Kukjin's for-next. Also, I'm curious whether or how this is has been tested on big.LITTLE SoCs. I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled. I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher. Also, the patch below[2] is needed for 5800. For reference, I had the same patch in a kernel tree we recently used for a demo on the chromebook 2 13 (Exynos 5800). We didn't see any stability issues due to this without CPUidle (using the ondemand govenor). The kernel we ended up using had CONFIG_BL_SWITCHER disabled, but i don't remember seeing stability issues when i did a testrun with that enabled. -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
[PATCH] phy: exynos5-usbdrd: Add MODULE_DEVICE_TABLE entry
Add a MODULE_DEVICE_TABLE call for OF match tables. This allows the
module to be autoloaded based on devicetree information.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/phy/phy-exynos5-usbdrd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index b05302b..e9a0f54 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -542,6 +542,7 @@ static const struct of_device_id
exynos5_usbdrd_phy_of_match[] = {
},
{ },
};
+MODULE_DEVICE_TABLE (of, exynos5_usbdrd_phy_of_match);
static int exynos5_usbdrd_phy_probe(struct platform_device *pdev)
{
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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: exynos: Explicitly set dr_mode on peach-pit and peach-pi
In case the optional dr_mode property isn't set in the dwc3 nodes the
the controller will go into OTG mode iff both USB host and USB gadget
functionality are enabled in the kernel configuration. Unfortunately this
results in USB not working on exynos5420-peach-pit and
exynos5800-peach-pi with such a kernel configuration unless manually
change the mode. To resolve that explicitely configure the dual role
mode as host
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 8
arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
arch/arm/boot/dts/exynos5800-peach-pi.dts | 8
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 228a6b1..6c22610 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -427,10 +427,18 @@
status = okay;
};
+usbdrd_dwc3_0 {
+ dr_mode = host;
+};
+
usbdrd_phy0 {
vbus-supply = usb300_vbus_reg;
};
+usbdrd_dwc3_1 {
+ dr_mode = host;
+};
+
usbdrd_phy1 {
vbus-supply = usb301_vbus_reg;
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index bfe056d..8617a03 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -815,7 +815,7 @@
#size-cells = 1;
ranges;
- dwc3 {
+ usbdrd_dwc3_0: dwc3 {
compatible = snps,dwc3;
reg = 0x1200 0x1;
interrupts = 0 72 0;
@@ -841,7 +841,7 @@
#size-cells = 1;
ranges;
- dwc3 {
+ usbdrd_dwc3_1: dwc3 {
compatible = snps,dwc3;
reg = 0x1240 0x1;
interrupts = 0 73 0;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index f3ee48b..166b352 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -425,10 +425,18 @@
status = okay;
};
+usbdrd_dwc3_0 {
+ dr_mode = host;
+};
+
usbdrd_phy0 {
vbus-supply = usb300_vbus_reg;
};
+usbdrd_dwc3_1 {
+ dr_mode = host;
+};
+
usbdrd_phy1 {
vbus-supply = usb301_vbus_reg;
};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Fix Exynos peach USB on kernels with USB Gadget support
When building a kernel with support for both USB host and USB Gadget support on the dwc3 controller on the Exynos5 soc will go into USB OTG mode unless otherwise specified in the dtb, which is unhelpful for boards hooked up to run as USB host. First patch in this set explicitely set the dual-role mode for the dwc3 controller on Peach pi and Peach pit boards to host mode. Second patch enables gadget mode in the default exynos config to more easily catch/trigger issues like these. I suspect other boards base using exynos5420/5800 might need the similar fixes (Arndale Octa and Samsung SMDK5420) to their dts files, so would be great if folks with those board could verify this. Sjoerd Simons (2): ARM: dts: exynos: Explicitly set dr_mode on peach-pit and peach-pi ARM: exynos_defconfig: enable USB gadget support arch/arm/boot/dts/exynos5420-peach-pit.dts | 8 arch/arm/boot/dts/exynos5420.dtsi | 4 ++-- arch/arm/boot/dts/exynos5800-peach-pi.dts | 8 arch/arm/configs/exynos_defconfig | 1 + 4 files changed, 19 insertions(+), 2 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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: exynos_defconfig: enable USB gadget support
Enable USB gadget support without support for any specific gadgets to more easily catch cases where a devices dts doesn't specify the usb controllers dr_mode while it should. Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index fc7d168..3664120 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -54,6 +54,7 @@ CONFIG_SMSC911X=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y +CONFIG_USB_GADGET=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y CONFIG_KEYBOARD_CROS_EC=y -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add of match tables for the ChromeOs EC subdevices
The ChromeOS EC MFD driver registers its sub-devices with both a (platform) name and an of compatibility string. As a result of this the modalias passed on to user-space will be based on the of compatibility string. Thus to be able to rely on autoloading in case the subdevices are build as modules they need to export the necessary module aliases based to match the of information. The two patches in these series add the requird of match information to the EC subdevices Sjoerd Simons (2): i2c: cros-ec-tunnel: Add of match table input: cros_ec_keyb: Add of match table drivers/i2c/busses/i2c-cros-ec-tunnel.c | 9 + drivers/input/keyboard/cros_ec_keyb.c | 10 ++ 2 files changed, 19 insertions(+) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] i2c: cros-ec-tunnel: Add of match table
To enable the cros-ec-tunnel driver to be auto-loaded when build as a
module add an of match table (and export it) to match the modalias
information passed on to userspace as the Cros EC MFD driver registers
the MFD subdevices with an of_compatibility string.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index 05e033c..3c15dcc 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -310,11 +310,20 @@ static int ec_i2c_remove(struct platform_device *dev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id cros_ec_i2c_of_match[] = {
+ { .compatible = google,cros-ec-i2c-tunnel },
+ {},
+};
+MODULE_DEVICE_TABLE(of, cros_ec_i2c_of_match);
+#endif
+
static struct platform_driver ec_i2c_tunnel_driver = {
.probe = ec_i2c_probe,
.remove = ec_i2c_remove,
.driver = {
.name = cros-ec-i2c-tunnel,
+ .of_match_table = of_match_ptr (cros_ec_i2c_of_match),
},
};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] input: cros_ec_keyb: Add of match table
To enable the cros_ec_keyb driver to be auto-loaded when build as
module add an of match table (and export it) to match the modalias
information passed on to userspace as the Cros EC MFD driver registers
the MFD subdevices with an of_compatibility string.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/input/keyboard/cros_ec_keyb.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 791781a..0bdbf2d 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -342,10 +342,20 @@ static int cros_ec_keyb_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(cros_ec_keyb_pm_ops, NULL, cros_ec_keyb_resume);
+#ifdef CONFIG_OF
+static const struct of_device_id cros_ec_keyb_of_match[] = {
+ { .compatible = google,cros-ec-keyb },
+ {},
+};
+MODULE_DEVICE_TABLE(of, cros_ec_keyb_of_match);
+#endif
+
+
static struct platform_driver cros_ec_keyb_driver = {
.probe = cros_ec_keyb_probe,
.driver = {
.name = cros-ec-keyb,
+ .of_match_table = of_match_ptr (cros_ec_keyb_of_match),
.pm = cros_ec_keyb_pm_ops,
},
};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/3] drm/exynos: Allow module to be autoloaded
On Tue, 2014-07-29 at 14:38 +0900, Inki Dae wrote: On 2014년 07월 28일 23:45, Sjoerd Simons wrote: Hey Inki, On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote: On 2014년 07월 28일 17:30, Sjoerd Simons wrote: Sorry for late, I don't see why Exynos drm driver should be auto-loaded module. I think all devices covered by Exynos drm framework are not hot-plugged. Maybe there is my missing point. So can you explain why Exynos drm driver should be auto-loaded module? The background for this is that I'm building a distribution-style multiplatform kernel, that is to say a kernel which can boot on a big set of different ARM boards. As such, the intention is to keep the core zImage as small as possible and essentially build things as far as possible as loadable modules. So in a sense, all of the hardware is hotplugged, depending on which board the kernel is actually booted on! For that use-case, exynosdrm needs to be able to build as a module (which it already can!) and it needs the required meta-data for userspace to know when it should be loaded. The latter is what my patch adds. It seems that you want that module data of sub drivers are added by depmod to /lib/modules/KERNEL_VERSION/modules.xxxmap because some hot-plug system should use modules.xxxmap file to find the proper driver to load. Yes. I would like the module to export its module alias information for the subdrivers such that depmod can add it to its databases and the normal module autoloading mechanisms work as intended. Note that in my case, some hot-plug system is really just udev, not something special.. Ok, then does exynos drm driver is loaded well with your patches? It is indeed. My concern is that device_id of exynos drm core driver , exynos_drm_drv.c, wouldn't be exported to userspace, which means that exynos drm subsystem aren't bound by component framework because most sub drivers except vidi are bound by component interfaces of exynos drm core: exynos drm drv is not device tree base driver. This patchset doesn't change how that works. Really all it does is to tell userspace which devices exynosdrm supports. From the kernel side of things, there is no difference between the module being loaded based on that information vs. it being loaded by hand. -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded
Hey Inki, On Mon, 2014-07-21 at 08:50 +0200, Sjoerd Simons wrote: Hey Inki, On Mon, 2014-07-21 at 12:02 +0900, Inki Dae wrote: On 2014년 07월 19일 05:36, Sjoerd Simons wrote: The exynos DRM module currently is not automatically loaded when build as a module. This is due to the simple fact that it doesn't have any MODULE_DEVICE_TABLE entries whatsoever... Most of these were removed previously as it wasn't possible at the time to have multiple calls to MODULE_DEVICE_TABLE in one module, however commit 21bdd17b21b45ea solved that. The first two patches revert the previous removals of MODULE_DEVICE_TABLE calls, while the last one adds calls for the remaining OF match tables without a MODULE_DEVICE_TABLE call. Exynos drm follows single-driver model. So each usb driver of Exynos drm wouldn't need its own MODULE_DEVICE_TABLE. Strictly speaking you're right, for module autoloading to work the module just needs to have one that matches. So in principle all other entries are redundant. However for exynos drm there does not seem to be one main device which is guaranteed to always be present which can be used to key the module autoloading of. So you still need seperate MODULE_DEVICE_TABLE entries for all the various subdrivers to ensure autoloading actually happens, especially since the various subdrivers can be seperately enabled at build time. Been about a week since this last mail. If you have any suggestions on a better approach or on how to move this forward, i'd be very grateful to hear as i think i've addressed your original comment on the set in the previous reply? -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded
Hey Inki, On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote: On 2014년 07월 28일 17:30, Sjoerd Simons wrote: Sorry for late, I don't see why Exynos drm driver should be auto-loaded module. I think all devices covered by Exynos drm framework are not hot-plugged. Maybe there is my missing point. So can you explain why Exynos drm driver should be auto-loaded module? The background for this is that I'm building a distribution-style multiplatform kernel, that is to say a kernel which can boot on a big set of different ARM boards. As such, the intention is to keep the core zImage as small as possible and essentially build things as far as possible as loadable modules. So in a sense, all of the hardware is hotplugged, depending on which board the kernel is actually booted on! For that use-case, exynosdrm needs to be able to build as a module (which it already can!) and it needs the required meta-data for userspace to know when it should be loaded. The latter is what my patch adds. -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded
Hey Inki, On Mon, 2014-07-21 at 12:02 +0900, Inki Dae wrote: On 2014년 07월 19일 05:36, Sjoerd Simons wrote: The exynos DRM module currently is not automatically loaded when build as a module. This is due to the simple fact that it doesn't have any MODULE_DEVICE_TABLE entries whatsoever... Most of these were removed previously as it wasn't possible at the time to have multiple calls to MODULE_DEVICE_TABLE in one module, however commit 21bdd17b21b45ea solved that. The first two patches revert the previous removals of MODULE_DEVICE_TABLE calls, while the last one adds calls for the remaining OF match tables without a MODULE_DEVICE_TABLE call. Exynos drm follows single-driver model. So each usb driver of Exynos drm wouldn't need its own MODULE_DEVICE_TABLE. Strictly speaking you're right, for module autoloading to work the module just needs to have one that matches. So in principle all other entries are redundant. However for exynos drm there does not seem to be one main device which is guaranteed to always be present which can be used to key the module autoloading of. So you still need seperate MODULE_DEVICE_TABLE entries for all the various subdrivers to ensure autoloading actually happens, especially since the various subdrivers can be seperately enabled at build time. The one exception from the above might be the HDMI sub-driver, which is always build together with the mixer (And i asume the HDMI hw block depends on the mixer block for its input). However it seems more elegant and less error-prone to have simply entries for both, rather then implicitly replying on the other (sub)driver to trigger module loading. Especially given there is essentially no cost in having another module alias. -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
[PATCH 0/3] drm/exynos: Allow module to be autoloaded
The exynos DRM module currently is not automatically loaded when build as a module. This is due to the simple fact that it doesn't have any MODULE_DEVICE_TABLE entries whatsoever... Most of these were removed previously as it wasn't possible at the time to have multiple calls to MODULE_DEVICE_TABLE in one module, however commit 21bdd17b21b45ea solved that. The first two patches revert the previous removals of MODULE_DEVICE_TABLE calls, while the last one adds calls for the remaining OF match tables without a MODULE_DEVICE_TABLE call. Sjoerd Simons (3): Revert drm/exynos: fix module build error Revert drm/exynos: remove MODULE_DEVICE_TABLE definitions drm/exynos: Add MODULE_DEVICE_TABLE entries for various components drivers/gpu/drm/exynos/exynos_dp_core.c | 1 + drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fimc.c| 1 + drivers/gpu/drm/exynos/exynos_drm_fimd.c| 1 + drivers/gpu/drm/exynos/exynos_drm_g2d.c | 1 + drivers/gpu/drm/exynos/exynos_drm_rotator.c | 1 + drivers/gpu/drm/exynos/exynos_hdmi.c| 1 + drivers/gpu/drm/exynos/exynos_mixer.c | 1 + 8 files changed, 8 insertions(+) -- 2.0.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] drm/exynos: Add MODULE_DEVICE_TABLE entries for various components
Add MODULE_DEVICE_TABLE calls for the various OF match tables that
currently don't have one. This allows the module to be
autoloaded based on devicetree information.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c| 1 +
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 1 +
drivers/gpu/drm/exynos/exynos_hdmi.c| 1 +
drivers/gpu/drm/exynos/exynos_mixer.c | 1 +
4 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 831dde9..ec7cc9e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1887,6 +1887,7 @@ static const struct of_device_id fimc_of_match[] = {
{ .compatible = samsung,exynos4212-fimc },
{ },
};
+MODULE_DEVICE_TABLE(of, fimc_of_match);
struct platform_driver fimc_driver = {
.probe = fimc_probe,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index f01fbb6..55af6b4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -691,6 +691,7 @@ static const struct of_device_id exynos_rotator_match[] = {
},
{},
};
+MODULE_DEVICE_TABLE(of, exynos_rotator_match);
static int rotator_probe(struct platform_device *pdev)
{
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index fd8141f..d08e00d 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2295,6 +2295,7 @@ static struct of_device_id hdmi_match_types[] = {
/* end node */
}
};
+MODULE_DEVICE_TABLE (of, hdmi_match_types);
static int hdmi_bind(struct device *dev, struct device *master, void *data)
{
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 9d0c21a..6756d1c 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1240,6 +1240,7 @@ static struct of_device_id mixer_match_types[] = {
/* end node */
}
};
+MODULE_DEVICE_TABLE(of, mixer_match_types);
static int mixer_bind(struct device *dev, struct device *manager, void *data)
{
--
2.0.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] Revert drm/exynos: remove MODULE_DEVICE_TABLE definitions
This reverts commit d089621896c3530a9bd309f96e9c9124d07f6c3f was
original to prevent multiple MODULE_DEVICE_TABLE in one module.
Which, as a side-effect broke autoloading of the module.
Since 21bdd17b21b45ea48e06e23918d681afbe0622e9 it is possible to have
multiple calls to MODULE_DEVICE_TABLE, so the patch can be
reverted to restore support for autoloading
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 1 +
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 845d766..31c3de9 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1376,6 +1376,7 @@ static const struct of_device_id exynos_dp_match[] = {
{ .compatible = samsung,exynos5-dp },
{},
};
+MODULE_DEVICE_TABLE(of, exynos_dp_match);
struct platform_driver dp_driver = {
.probe = exynos_dp_probe,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 2df3592..46b7bf6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1529,6 +1529,7 @@ static struct of_device_id exynos_dsi_of_match[] = {
{ .compatible = samsung,exynos4210-mipi-dsi },
{ }
};
+MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
struct platform_driver dsi_driver = {
.probe = exynos_dsi_probe,
--
2.0.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] Revert drm/exynos: fix module build error
This reverts commit de1d3677017a1d58419722b60564cb56bd9462c3, which was
original added to fix build errors when building exynosdrm as a single
module caused by multiple MODULE_DEVICE_TABLE in one module. Which, as
a side-effect broke autoloading of the module.
Since 21bdd17b21b45ea48e06e23918d681afbe0622e9 it is possible to have
multiple calls to MODULE_DEVICE_TABLE, so the patch can be
reverted to restore support for autoloading
Conflicts:
drivers/gpu/drm/exynos/exynos_drm_fimd.c
drivers/gpu/drm/exynos/exynos_drm_g2d.c
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 +
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 33161ad..081eb15 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -136,6 +136,7 @@ static const struct of_device_id fimd_driver_dt_match[] = {
.data = exynos5_fimd_driver_data },
{},
};
+MODULE_DEVICE_TABLE(of, fimd_driver_dt_match);
static inline struct fimd_driver_data *drm_fimd_get_driver_data(
struct platform_device *pdev)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 8001587..bb728c8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1546,6 +1546,7 @@ static const struct of_device_id exynos_g2d_match[] = {
{ .compatible = samsung,exynos5250-g2d },
{},
};
+MODULE_DEVICE_TABLE(of, exynos_g2d_match);
struct platform_driver g2d_driver = {
.probe = g2d_probe,
--
2.0.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers: phy: phy-samsung-usb2.c: Add missing MODULE_DEVICE_TABLE
Allow phy-exynos-usb2 to be autoloaded based on devicetree information.
Tested on Odroid X2 with its USB subsystem build as modules.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/phy/phy-samsung-usb2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-samsung-usb2.c
index 8a8c6bc..1e69a32 100644
--- a/drivers/phy/phy-samsung-usb2.c
+++ b/drivers/phy/phy-samsung-usb2.c
@@ -107,6 +107,7 @@ static const struct of_device_id
samsung_usb2_phy_of_match[] = {
#endif
{ },
};
+MODULE_DEVICE_TABLE(of, samsung_usb2_phy_of_match);
static int samsung_usb2_phy_probe(struct platform_device *pdev)
{
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers: phy: exynos4x12-phy: Add missing MODULE_DEVICE_TABLE
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/phy/phy-samsung-usb2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-samsung-usb2.c
index 8a8c6bc..1e69a32 100644
--- a/drivers/phy/phy-samsung-usb2.c
+++ b/drivers/phy/phy-samsung-usb2.c
@@ -107,6 +107,7 @@ static const struct of_device_id
samsung_usb2_phy_of_match[] = {
#endif
{ },
};
+MODULE_DEVICE_TABLE(of, samsung_usb2_phy_of_match);
static int samsung_usb2_phy_probe(struct platform_device *pdev)
{
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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: Remove outdated usb2 phy entry from exynos5250.dtsi
The exynos5250.dtsi has two entries for describing the usb2 phy. One for
the newer driver using the generic PHY framework and one for its
predecessor. The older node is only referenced by the arndale dts, which
seems redundant given starting from dba2f05880c the common dtsi also
includes the phy entries.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
arch/arm/boot/dts/exynos5250-arndale.dts | 4
arch/arm/boot/dts/exynos5250.dtsi| 15 ---
2 files changed, 19 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..dad8f9b 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -570,8 +570,4 @@
connect-gpios = gpd1 7 1;
};
};
-
- usb@1211 {
- usb-phy = usb2_phy;
- };
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 834fb5a..7c545d50 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -600,21 +600,6 @@
};
};
- usb2_phy: usbphy@1213 {
- compatible = samsung,exynos5250-usb2phy;
- reg = 0x1213 0x100;
- clocks = clock CLK_FIN_PLL, clock CLK_USB2;
- clock-names = ext_xtal, usbhost;
- #address-cells = 1;
- #size-cells = 1;
- ranges;
-
- usbphy-sys {
- reg = 0x10040704 0x8,
- 0x10050230 0x4;
- };
- };
-
usb2_phy_gen: phy@1213 {
compatible = samsung,exynos5250-usb2-phy;
reg = 0x1213 0x100;
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
