Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler

[Doug Anderson]

Hi,

On Thu, Oct 22, 2015 at 9:07 AM, Javier Martinez Canillas
 wrote:
>> Note that personally I would only choose the "highest" priority as an
>> absolute last resort.  Leaving a little extra slack in there means
>> that when the next person comes up with a really good reason to run
>> before you do that they can do it without changing your code.  All
>> good BASIC programmers know to skip "10" in their first version for
>> just this reason.  ;)
>>
>> If I were to pick a number, I suppose I'd pick something like "220",
>> but that's pretty arbitrary.  I would have picked 200 except that it
>> appears that would race with veyron's choice.
>>
>
> Yes, I actually gave some thought about choosing a number since I didn't
> want to come with another arbitrary one. That's why I tried to understand
> the policy as I mentioned before but I didn't find anything besides the
> values listed in the register_restart_handler() doc: 0, 128 and 255.
>
> It seems that most default system restart handlers use 128 and that's
> the reason why gpio-restart and mmc-pwrseq-emmc use 129 and other restart
> handlers that can be registered via DT use 192 (which is in the middle of
> 128 and 255).
>
> So I actually thought to use a number in between 192 and 255 (i.e: 220)
> but then there could be another platform that uses 221 instead of 200
> so eMMC restart won't work there. That's why I finally chose the highest.
>
> Do you know why the priority 200 was chosen for veyron gpi-restart ooi?

In David Riley's original patch the example had 200:
https://patchwork.kernel.org/patch/4784611/

In the ChromeOS 3.14 kernel tree I believe we're still using the old
patch (we still have /bits/ 8).  ...it looks like I'm the one who
originally added it to the veyron dts file and I set it to 200, so I'd
presume that I just copied the example and called it "good enough".

I'm sure the upstream dts just used the number from the ChromeOS 3.14 tree...

Note that the GPIO-restart definitely need to be higher priorities
than others in the system.  The two I know of off the top of my head
are the "dw watchdog" and the one in the CRU.  The "dw watchdog" has a
priority of 128 and so does the one in "rockchip/clk.c".  Hrm,
actually, the Rockchip-specific one should probably have its priority
bumped up since it seems better not to just randomly pick between
these two...


-Doug
--
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] mmc: pwrseq: Use highest priority for eMMC restart handler

[Doug Anderson]

Krzysztof,

On Wed, Oct 21, 2015 at 6:43 PM, Krzysztof Kozlowski
 wrote:
> I think at least one platform may be affected because it used
> mmc-pwrseq-emmc and gpio-restart.
>
> Look at rk3288-veyron.dtsi.
>
> Both of restart handlers had the priority of 129 which means that the
> order of execution depends on probing sequence. Now you will make the
> sequence strict - first mmc then gpio.
>
> You seems convinced that this is not a problem... I don't know. I would
> prefer test this on affected platforms before risking to break them.
> It's annoying if fix for one SoC breaks another.

Assuming I'm understanding things properly, veyron isn't using 129 as
a priority.  In the dts file:

gpio-restart {
compatible = "gpio-restart";
gpios = < 13 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <_warm_reset_h>;
priority = <200>;
};

...so it overrides the default 129 with 200.  Ah, but Javier already
pointed that out in his reply.

>> Since the current mmc_pwrseq_emmc_reset_nb notifier priority is 129,
>> eMMC reset will not work if one of the platforms you mentioned needs
>> this since the system restart handler with prio 192 will be executed
>> before the eMMC one, leaving the eMMC in an unknown state on reboot.
>
> And now you will "fix this" by making eMMC working correctly. So let's
> make it straight:
> 1. Previously the eMMC could be left on these platforms in an unknown
> state (because emmc handler was not executed).
> 2. No one complained! Which could mean that in fact this was working fine...
> 3. Now you will change it.
> 4. Maybe someone will complain?

On veyron boards the reset shouldn't hurt.  The eMMC reset will
actually get asserted at reset anyway since the reset will reset GPIO
states and the default GPIO state for the eMMC line asserts reset.

OK, I just picked this onto Heiko's somewhat "stable-tree"
(v4.3-rc3-876-g6509232) from
.  I put printouts in
__mmc_pwrseq_emmc_reset() to confirm it was getting called.  I then
rebooted.  I then saw:

[   36.175732] reboot: Restarting system
[   36.179400] DOUG: resetting emmc
[   36.182829] DOUG: resetting emmc done

...and the reboot worked normally (which means that the GPIO restart
got called since otherwise I would have gotten TPM errors).

So I'd say that for rk3288-veyron-jerry:

Tested-by: Douglas Anderson 


Note that personally I would only choose the "highest" priority as an
absolute last resort.  Leaving a little extra slack in there means
that when the next person comes up with a really good reason to run
before you do that they can do it without changing your code.  All
good BASIC programmers know to skip "10" in their first version for
just this reason.  ;)

If I were to pick a number, I suppose I'd pick something like "220",
but that's pretty arbitrary.  I would have picked 200 except that it
appears that would race with veyron's choice.

-Doug
--
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 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support

[Doug Anderson]

Hi,

On Mon, Oct 19, 2015 at 3:11 AM, Anand Moon  wrote:
> 1 Drop the cd-gpios changes. pinctrl-0 changes.

Right.


> 2 Fix the regulator changes for vmmc/vqmmc with disable of 
> regulator-always-on;

I'm not totally sure I understand.  You should need to keep vmmc and
vqmmc always on because otherwise you can't do card detection (unless
you poll for card detect).


> 3 Drop this UHS-I changes as if now.

Sounds right.
--
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 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support

[Doug Anderson]

Hi,

On Tue, Oct 13, 2015 at 6:06 PM, Alim Akhtar  wrote:
> +Doug
> Hello,
> AFAIR, dw_mmc host controller does support UHS-I [1], specially SDR50
> and SDR104 modes.
>
> [1]: http://www.spinics.net/lists/linux-mmc/msg28186.html
>
> What I remember is, one need to set "broken-cd" property also in order
> to make it work because of the vqmmc and vmmc connection on board. I
> didn't find the link right now, but you can search on the web, there
> was a long discussion about handling this.
> Have not checked it recently, so not sure if this got broken somehow.

Right.  It _shouldn't_ be possible to add "vmmc/vqmmc" supplies to
your DTS (which you do in patch 2/3) and also to use the "gpc2-2" pin
for card detect (even if you configure it as a GPIO).  Once you add
"vmmc/vqmmc" then Linux ought to be turning these regulators off when
no card is plugged in.  Presumably the "vqmmc" regulator is hooked up
to the "VDDQ_MMC2".  If you look in the user manual for 5422 you can
see that "GPC2[2]/SD_2_CDn" has power domain "VDDQ_MMC2".  Thus you
really shouldn't be using that pin when vqmmc is off.  I think at some
point someone claimed that it still worked for them, but nobody could
ever explain why.  Full discussion at


---

In case it matters, comments on stuff from earlier in the thread:

* As people pointed out, exynos5422 certainly supports all these modes
(including DDR50) in the SoC.

* Just because the SoC supports these modes doesn't mean that the
boards do, which is why the SoC .dtsi doesn't include them.  Thus,
this patch is "right" in that it changes a board-specific file.

* As Krzysztof points out this board doesn't "add" support but rather
"enables" support.  The distinction is subtle.

* You might be able to get DDR50 working, but probably better to just
start with SDR modes.  Previously I never attempted to get DDR50 cards
working, so possibly the software needs extra work?


-Doug
--
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 Exynos5250 Snow Rev5+ support

[Doug Anderson]

Hi,

On Wed, Sep 30, 2015 at 4:44 PM, Krzysztof Kozlowski
 wrote:
>> Switching the default meaning of "google,snow" to Rev5 is probably not
>> something we'd ever want to do, since it could confuse "rev3" boards
>> (which should be serviced by the rev4 dts).  From comments in the
>> Chrome OS tree:
>>
>> In the "rev4" DTS:
>>  * - Any real rev 0-3 boards in the field will match "google,snow",
>>  *   since older U-Boots don't look for a revision specific device 
>> tree.
>>  * - Any real rev 4 boards in the field will match "google,snow-rev4"
>>  *   first.  If that's not present they will pick the first
>>  *   "google,snow" device tree that they find (ignoring the kernel
>>  *   ordering).
>>
>> In the "rev5" DTS:
>>  * - Purposely don't add "google,snow" so old firmware (which didn't
>>  *   include a -revN suffix) won't pick this one.
>
> These are requirements written somewhere in the downstream tree... not
> in upstream. Have in mind that someone may not be using Chrome OS on
> Chromebook but custom U-Boot and different distro.
>
> You cannot expect that everyone will new some requirements of some
> downstream OS. If you need such requirements, write them in bindings
> documentation *in the upstream*.

Agreed, which is why I bring it up here.  I think Javier wasn't aware
of these when he sent up his patch.  I believe when he adds the
bindings docs he'll put this information.

Previously rev5 wasn't supported upstream and I believe rev5 didn't
even exist when the upstream stuff was submitted.

-Doug
--
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 Exynos5250 Snow Rev5+ support

[Doug Anderson]

Hi,

On Tue, Sep 29, 2015 at 5:30 PM, Krzysztof Kozlowski
 wrote:
> Now the exynos5250-snow.dts means in fact Rev4... but there is no
> information in DTS about it. I think adding compatible
> "google,snow-rev4" makes sense:
> 1. For informational purposes (this could be also handled with a comment).
> 2. Later one could decide to switch the default meaning of "google,snow"
> to Rev5 and the real compatible (rev4) will be there already.
>
> Could you add the new compatible and fix patch issues pointed by Doug?

Looks like everything got applied, but just for the record:

Switching the default meaning of "google,snow" to Rev5 is probably not
something we'd ever want to do, since it could confuse "rev3" boards
(which should be serviced by the rev4 dts).  From comments in the
Chrome OS tree:

In the "rev4" DTS:
 * - Any real rev 0-3 boards in the field will match "google,snow",
 *   since older U-Boots don't look for a revision specific device tree.
 * - Any real rev 4 boards in the field will match "google,snow-rev4"
 *   first.  If that's not present they will pick the first
 *   "google,snow" device tree that they find (ignoring the kernel
 *   ordering).

In the "rev5" DTS:
 * - Purposely don't add "google,snow" so old firmware (which didn't
 *   include a -revN suffix) won't pick this one.


-Doug
--
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 Exynos5250 Snow Rev5+ support

[Doug Anderson]

Javier,

On Tue, Sep 29, 2015 at 4:57 AM, Javier Martinez Canillas
 wrote:
> There are 2 revisions of the Exynos5250 Snow Chromebook that were shipped:
> Rev4 and Rev5. The only difference between these 2 revisions is the codec,
> Rev4 has a max98095 codec while Rev5 has a max98090.
>
> Mainline only supports Rev4 so this patch moves the common device nodes to
> a DTSI file and adds a DTS for the Exynos5250 Snow Rev5.
>
> The Snow Rev5 DTS is based on the DTS found in the ChromiumOS 3.8 tree.
>
> Signed-off-by: Javier Martinez Canillas 
>
> ---
>
> The DTS in the vendor ChromeOS tree are called exynos5250-snow-rev{4,5}.dtb
> but I decided to leave Rev4 as exynos5250-snow.dtb to avoid breaking u-boot
> that has CONFIG_DEFAULT_DEVICE_TREE="exynos5250-snow" in snow_defconfig.
>
> Also, ChromiumOS Rev4 DTS has "google,snow-rev4" in its compatible string
> but was not added in mainline since Rev4 firmware fallbacks to "google,snow"
> and Rev5 searches for "google,snow-rev5". That way the compatible string
> could be consistent with the DTS naming and still be able to pack both Rev4
> and Rev5 FDT in the same FIT image and let the firmware pick the correct FDT.

Looking at all the notes in the DTS in the ChromeOS tree, this sounds
like it should be fine.


>  arch/arm/boot/dts/Makefile|   1 +
>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 
> ++
>  arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
>  arch/arm/boot/dts/exynos5250-snow.dts | 666 +
>  4 files changed, 733 insertions(+), 665 deletions(-)

Thanks!  Note:

$ pwclient git-am 7285451
Applying patch #7285451 using 'git am'
Description: ARM: dts: Add Exynos5250 Snow Rev5+ support
Applying: ARM: dts: Add Exynos5250 Snow Rev5+ support
.git/rebase-apply/patch:774: new blank line at EOF.
+
warning: 1 line adds whitespace errors.


One other nit is that the exynos5250-snow.dts" ends up with the
"max98095" pinctrl properties sorted differently than the
"exynos5250-snow-rev5.dts".  Is it worth reordering the
"exynos5250-snow.dts" in the same patch?

Otherwise this looks fine to me.

Reviewed-by: Douglas Anderson 
--
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 PATCH v5 1/9] mmc: dw_mmc: Add external dma interface support

[Doug Anderson]

Heiko,

On Fri, Aug 14, 2015 at 3:13 PM, Heiko Stübner he...@sntech.de wrote:
 Hi Shawn,

 Am Freitag, 14. August 2015, 16:34:35 schrieb Shawn Lin:
 DesignWare MMC Controller can supports two types of DMA
 mode: external dma and internal dma. We get a RK312x platform
 integrated dw_mmc and ARM pl330 dma controller. This patch add
 edmac ops to support these platforms. I've tested it on RK312x
 platform with edmac mode and RK3288 platform with idmac mode.

 Signed-off-by: Shawn Lin shawn@rock-chips.com

 judging by your from, I guess you're running this on some older Rockchip soc
 without the idma? Because I tried testing this on a Radxa Rock, but only got
 failures, from the start (failed to read card status register). In PIO mode
 everything works again.


 I guess I overlooked just some tiny detail, but to me the dma channel ids seem
 correct after all. Maybe you have any hints what I'm doing wrong?

If I were a guessing man (which I'm not), I'd guess that perhaps
you're running into troubles with our friend the PL330.

There appear to be strange issues with the PL330 on Rockchip SoCs.  I
was only peripherally involved with them, but I know at least about
some of the patches in our tree, like:

https://chromium-review.googlesource.com/237607
FROMLIST: DMA: pl330: support burst mode for dev-to-mem and mem-to-dev transmit

https://chromium-review.googlesource.com/237393
CHROMIUM: dmaengine: pl330: support quirks for some broken

https://chromium-review.googlesource.com/237396
CHROMIUM: dmaengine: pl330: add quirk for broken no flushp

https://chromium-review.googlesource.com/237394
CHROMIUM: ARM: dts: rockchip: Add broken-no-flushp into rk3288.dtsi

https://chromium-review.googlesource.com/242063
CHROMIUM: ASoC: rockchip_i2s: modify DMA max burst to 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

Re: [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor

[Doug Anderson]

Hi,

On Tue, Jul 28, 2015 at 9:20 AM, Alexey Klimov klimov.li...@gmail.com wrote:
 Hi Doug,

 On Tue, Jul 28, 2015 at 6:24 PM, Doug Anderson diand...@chromium.org wrote:
 Alexey,

 On Mon, Jul 27, 2015 at 2:28 PM, Alexey Klimov klimov.li...@gmail.com 
 wrote:
 Hi all,

 year(s) ago it was discovered that MCT timer and ARM architectured
 timer
 are the same hardware with different interface. Here [1].

 I followed mail-list discussions about removing MCT and using arch
 timer for Exynos5-based SoCs but things aren't moving at least latest
 upstream kernel on odroid-xu3 will use MCT as default timers.
 Maybe the reason are some power-management related things that very
 specific to Samsung. I don't know.


 Idea of this draft patchset comes from Doug patches when he tried to
 optimize read of 64-bit counter located in mmio. [2]
 Why not using cp15 counter instead if possible?

 I hate to burst your bubble here, but...

 ...I think it would be a bad idea to use the cp15 counter on exynos
 5422.  According to Samsung, there are issues where using cp15 could
 sometimes return the wrong value, especially if you happen to read it
 while on an A7 instead of an A15.  It will tend to work pretty well,
 but Samsung claimed that it might not work right on some CPUs or at
 some temperatures.

 I think this is right time when I can say If only I had known about
 it before!.

Yeah, we spent a whole lot of time on this too before giving up after
we found out it was not possible to use.


 That's quite interesting especially about temperature issues.
 Maybe it's worth to insert comments in driver/docs about this.

Maybe not a bad idea.  Depends if you think someone else will try to
do this...  ...and if they do, will they check mailing list traffic.


 Generally I'd say that if the arch timer works for you: use the arch
 timer.  If the arch timer doesn't work for you, use the MCT.

 -Doug

 I possess no knowledge if there're any different hw revisions of
 odroid-xu3 on the field
 but looks like arch timer works fine for me on odroid-xu3 Exynos5422
 SoC with upstream kernel.

Well, it looked like it worked for us too.  In fact, I never saw a
failure.  All I know is that Samsung said: don't do this, it's not a
good idea.  The performance gain wasn't enough to go against that...
That's when I started trying to optimize the MCT a little bit.  ;)


-Doug
--
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 PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor

[Doug Anderson]

Alexey,

On Mon, Jul 27, 2015 at 2:28 PM, Alexey Klimov klimov.li...@gmail.com wrote:
 Hi all,

 year(s) ago it was discovered that MCT timer and ARM architectured
 timer
 are the same hardware with different interface. Here [1].

 I followed mail-list discussions about removing MCT and using arch
 timer for Exynos5-based SoCs but things aren't moving at least latest
 upstream kernel on odroid-xu3 will use MCT as default timers.
 Maybe the reason are some power-management related things that very
 specific to Samsung. I don't know.


 Idea of this draft patchset comes from Doug patches when he tried to
 optimize read of 64-bit counter located in mmio. [2]
 Why not using cp15 counter instead if possible?

I hate to burst your bubble here, but...

...I think it would be a bad idea to use the cp15 counter on exynos
5422.  According to Samsung, there are issues where using cp15 could
sometimes return the wrong value, especially if you happen to read it
while on an A7 instead of an A15.  It will tend to work pretty well,
but Samsung claimed that it might not work right on some CPUs or at
some temperatures.

I've added Alim who provided this information to me (in the private
http://crosbug.com/p/29556).  He may be able to elaborate more.

Generally I'd say that if the arch timer works for you: use the arch
timer.  If the arch timer doesn't work for you, use the MCT.

-Doug
--
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 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend

[Doug Anderson]

Hi,

On Fri, Jun 12, 2015 at 12:36 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 registers are lost assuming the combiner was powered down, even the
 status register will be lost and you will not know exactly the wakeup
 reason right ?


 Good question, I didn't find in the documentation I've access to that
 this happen but just found through experimentation that the IRQ enable
 set register values are lost after a resume and that saving/restoring
 the values makes the interrupts to be triggered again.


 I'll share here too the findings I mentioned over IRC. As you suggested I
 add some printouts and noticed that the ISTRn (Interrupt Status) registers
 values are indeed preserved on resume so I can know for example if the
 wakeup source was the power gpio-key or cros_ec keyboard. I've checked the
 values of the registers against the Exynos manual and they corresponds to
 the interrupt sources in each case so the values are correct.

 So as you said, it seems that is not that the IP block loses its state on
 S2R but that something is blindly writing the IESRn (Interrupt Enable Set)
 registers.

I'll postulate an alternate theory here.  You can tell me if you buy
it or if you think I've been out in the sun too long.

Let's say that the interrupt combiner's status registers show the raw
status as asserted by whatever is hooked up to the combiner.  This
means that even if the combiner got reset we could still read the
status register and get the status of the source.  Imagine that the
combiner is like a GPIO bank.  If you reset the GPIO bank, you'll lose
all kinds of config (input vs. output, edge interrupt status, maybe
pulls, etc).  ...but you can still read the state asserted by an
external source, right?

In this case the combiner's interrupt source is 'EINT 11'.  ...and I'm
pretty sure that the controller managine 'EINT 11' _doesn't_ lose
power across suspend/resume...


I'll further bolster my theory by saying that _almost nothing_ in the
exynos keeps power across suspend/resume.  The UART?  Nope.  The GPIO
controllers?  Nuh-uh.  The GIC?  Sorry, but no.  The clock tree?  It
might be nice, but you're out of luck.  ...so it would make me
terribly surprised to see the combiner keep power.


 To reduce the possible s/w components that could be doing this, I booted a
 signed FIT image directly using the RO U-Boot instead of chain loading a
 mainline nv-uboot. In this configuration I've the same issue so it seems
 that if something is zeroing those registers on S2R, this can't be changed
 without void the warranty of these machines.

 I also looked at the downstream ChromiumOS v3.8 tree [0] and I see that
 they have a very similar solution than my patch, the IESRn are also saved
 but using a notifier for the CPU_PM_ENTER and CPU_PM_EXIT events instead
 or registering a syscore ops but the idea is basically the same.

Yup, you can see where kliegs added it in
https://chromium-review.googlesource.com/#/c/27964/.  As per the
comments in that CL, this was probably broken in:

063bd6f ARM: EXYNOS: Remove GIC save  restore function


 I have to take a look to the U-boot that is shipped on the device, I think
 the correct branch is [1] but I'm not sure if that is the correct one.

It is the right one.  If U-Boot were touching this (which would
greatly surprise me) it should be here:

arch/arm/include/asm/arch-exynos/cpu.h

...and it's not.  Doing a grep for '1044' (the combiner base
address) doesn't find anything in U-Boot either, which makes it less
likely.  ...and it's even less likely since the amount of code that is
in U-Boot that runs at resume time is a very small subset and I'm
fairly familiar with it and I would have remembered it touching the
combiner.

It's POSSIBLE that the internal ROM in exynos is clobbering this, but
as per above it seems crazy unlikely and I think it's just losing
power.


-Doug
--
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 1/1] ARM: dts: Add keep-power-in-suspend to WiFi SDIO node for Peach Boards

[Doug Anderson]

Javier,

On Tue, Apr 7, 2015 at 6:03 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 The Marvell mwifiex driver prevents the system to enter into a suspend
 state if the card power is not preserved during a suspend/resume cycle.

 So Suspend-to-RAM and Suspend-to-idle is failing on Exynos5800 Peach Pi
 and Exynos5420 Peach Pit Chromebooks.

 Add the keep-power-in-suspend Power Management property to the SDIO/MMC
 node so the mwifiex suspend handler doesn't fail and the system is able
 to enter into a suspend state.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 +
  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 1 +
  2 files changed, 2 insertions(+)

Reviewed-by: Doug Anderson diand...@chromium.org
--
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] ASoC: samsung: Extend Snow driver to support max98089

[Doug Anderson]

Andreas,

On Thu, Feb 19, 2015 at 9:56 AM, Andreas Färber afaer...@suse.de wrote:
 Am 19.02.2015 um 18:44 schrieb Doug Anderson:
 On Thu, Feb 19, 2015 at 1:44 AM, Mark Brown broo...@kernel.org wrote:
 On Wed, Feb 18, 2015 at 07:25:58PM +0100, Andreas Färber wrote:

  static const struct of_device_id snow_of_match[] = {
 + { .compatible = google,snow-audio-max98089, },
   { .compatible = google,snow-audio-max98090, },
   { .compatible = google,snow-audio-max98091, },
   { .compatible = google,snow-audio-max98095, },

 Since we completely ignore the CODEC in the property might it not be
 better to just add a plain old snow-audio compatible and bind to that,
 that way we don't need these driver updates?  Just the snow bit should
 be enough to know it's one of this class of machines.

 I think what you're suggesting is that here we should add a new
 compatible string google,snow-audio instead of adding
 google,snow-audio-max98089 here.  Then the sound node in the spring
 DTS would look like:

   compatible = google,snow-audio-max98089, google,snow-audio;

 If we want to be specific just in case, was it an active decision not to
 use google,peach-pi[t]-audio-max98...?

 Again, either way works for me.

I don't think it was an active decision, but I am certainly nowhere
near an audio expert and I don't think I made that particular decision
(I could be wrong).

One could make the argument that snow describes the general hookup
style of the hardware and then you list the actual codec after that,
but that's a pretty weak argument...

-Doug
--
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] ASoC: samsung: Extend Snow driver to support max98089

[Doug Anderson]

Mark,

On Thu, Feb 19, 2015 at 1:44 AM, Mark Brown broo...@kernel.org wrote:
 On Wed, Feb 18, 2015 at 07:25:58PM +0100, Andreas Färber wrote:

  static const struct of_device_id snow_of_match[] = {
 + { .compatible = google,snow-audio-max98089, },
   { .compatible = google,snow-audio-max98090, },
   { .compatible = google,snow-audio-max98091, },
   { .compatible = google,snow-audio-max98095, },

 Since we completely ignore the CODEC in the property might it not be
 better to just add a plain old snow-audio compatible and bind to that,
 that way we don't need these driver updates?  Just the snow bit should
 be enough to know it's one of this class of machines.

I think what you're suggesting is that here we should add a new
compatible string google,snow-audio instead of adding
google,snow-audio-max98089 here.  Then the sound node in the spring
DTS would look like:

  compatible = google,snow-audio-max98089, google,snow-audio;

That would allow us to later figure out that we're on a board with
max98089 in case it became important but means that any other minor
tweaks like this wouldn't need anything special.  I haven't tried that
to make sure that the fallback compatible string actually works in
this case, but it seems like the right way to go...

Sound good?

-Doug
--
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 1/6] ASoC: max98088: Document DT bindings

[Doug Anderson]

Andreas,

On Thu, Feb 19, 2015 at 6:13 AM, Andreas Färber afaer...@suse.de wrote:
 I see that a master clock (mclk) is added in patch 6/6 but the
 max98088 codec driver does handle this clock.

 If the SoC XCLKOUT provides the master clock to the max98089
 codec in Spring like is the case for the max9809{0,5} codecs
 in the Snow and Peach Pit/Pi Chromebooks then you need to do
 something along the lines of the following commits:

 e3048c3d2be5 ASoC: max98095: Add master clock handling
 b10ab7b838bd ASoC: max98090: Add master clock handling

 If that's the case you also have to mention in the DT binding
 doc that clocks and clock-names are optional properties
 like Documentation/devicetree/bindings/sound/max9809{0,5}.txt.

 When I prepared this patch, I believe it was a straight copy from
 max98090. Sounds like they changed since then.

 My 6/6 adopted the mclk clock from your now-cancelled v2 patch for Snow,
 assuming it would be the same on all Chromebooks. I tested that last
 change by checking for errors in dmesg.

 Doug, can you advise on how the clock wiring is for Spring?

I can confirm that XCLKOUT is connected to the codec MCLK on the
Spring schematics I have.

-Doug
--
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] mmc: dw_mmc: exynos: remove incorrect __exit_p()

[Doug Anderson]

Dmitry,

On Fri, Jan 23, 2015 at 4:33 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 dw_mci_pltfm_remove() is not (nor should it be) marked as __exit,
 so we should not be using __exit_p() wrapper with it.

 Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
 ---
  drivers/mmc/host/dw_mmc-exynos.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Nice catch, thanks!

Reviewed-by: Doug Anderson diand...@chromium.org
Tested-by: Doug Anderson diand...@chromium.org
--
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 v3 1/4] mmc: dw_mmc: exynos: incorporate ciu_div into timing property

[Doug Anderson]

Alim,

On Sun, Jan 4, 2015 at 2:43 PM, Alim Akhtar alim.akh...@gmail.com wrote:
 You are breaking backward compatibility here.  If your change is
 merged then all old boards will instantly break.  Since the dts and
 code changes will likely be merged through different trees you'll end
 up with a bunch of broken trees until everything is merged together.
 Even if you don't subscribe to the stable bindings theory this is not
 acceptable.

 yes the major concern in this series is probably this, which breaks
 things unless everything merge in one go and via one tree. Thats why I
 re-based everything including dts change on mmc-tree for this case and
 added device-tree mailing list for more opinion etc.

Got it.  I doubt that folks will like this, but I could be wrong.  In
order for this to work, you'd need all changes in the series to land
in _both_ the ARMSoC tree and the MMC tree.  That's not unheard of,
but it doesn't seem ideal.

You also break bisect-ability here since without the code the DTS
change will break things and without the DTS change the code will
break things.

If you add all the above to the fact that bindings are supposed to be
stable (ish) I'm not convinced this will land.


-Doug
--
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 v3 1/4] mmc: dw_mmc: exynos: incorporate ciu_div into timing property

[Doug Anderson]

Alim,

On Tue, Dec 30, 2014 at 10:43 PM, Alim Akhtar alim.akh...@samsung.com wrote:
 From: Seungwon Jeon tgih@samsung.com

 ciu_div may not be common value for all speed mode.
 So, it needs to be attached to CLKSEL timing.

The more time I've spent looking at all of this stuff the less I like
the exynos bindings.  Personally I'd prefer to see the exynos bindings
fixed rather than go further down the path of these bindings.

Specifically:

1. The drive really should be specified quite differently.
According to the DesignWare docs, the drive phase is there to meet
hold time requirements.  Hold time requirements are different for
different SD/MMC modes and are specified in nanoseconds (SDR104 is
.8ns, ID mode is 5.0ns).  There is a per-SoC parameter needed that
indicates some built-in delay (in nanoseconds) and that shouldn't
change based on clock speed or card mode.

2. The ciu_div really ought to be automatic.  Start out at a divide by
4.  If you end up with both drive and sample at phases of 0, 90, 180,
270 then you can change to divide by 2.

I still haven't looked at every last detail of these delays though, so
please correct me if I'm wrong.  I've added Alex who may have looked
at this more than I have.


With all of the above, there's also the fact that (I think) we should
be moving towards working with the clock phase API since all of your
values are effectively specifying clock phases, just in a very arcane
way.


 This also introduce a new compatibale 'dw-mshc-hs200-timing'
 for selecting hs200 timing value

As per above, I don't think this is needed.


 Signed-off-by: Seungwon Jeon tgih@samsung.com
 Signed-off-by: Alim Akhtar alim.akh...@samsung.com
 ---
  .../devicetree/bindings/mmc/exynos-dw-mshc.txt |   15 ++--
  drivers/mmc/host/dw_mmc-exynos.c   |   81 
 ++--
  drivers/mmc/host/dw_mmc-exynos.h   |1 +
  3 files changed, 67 insertions(+), 30 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt 
 b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 index ee4fc05..06455de 100644
 --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 @@ -23,10 +23,6 @@ Required Properties:
 - samsung,exynos7-dw-mshc-smu: for controllers with Samsung Exynos7
   specific extensions having an SMU.

 -* samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface
 -  unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
 -  ignored for Exynos4 SoC's. The valid range of divider value is 0 to 7.
 -
  * samsung,dw-mshc-sdr-timing: Specifies the value of CIU clock phase shift 
 value
in transmit mode and CIU clock phase shift value in receive mode for single
data rate mode operation. Refer notes below for the order of the cells and 
 the
 @@ -37,11 +33,16 @@ Required Properties:
data rate mode operation. Refer notes below for the order of the cells and 
 the
valid values.

 +* samsung,dw-mshc-hs200-timing: Similar with dw-mshc-sdr-timing.
 +
Notes for the sdr-timing and ddr-timing values:

  The order of the cells should be
- First Cell: CIU clock phase shift value for tx mode.
- Second Cell: CIU clock phase shift value for rx mode.
 +  - Thrid Cell: Specifies the divider value for the card interface
 +unit (ciu) clock. This property is applicable only for Exynos5 SoC's 
 and
 +ignored for Exynos4 SoC's. The valid range of divider value is 0 to 
 7.

  Valid values for SDR and DDR CIU clock timing for Exynos5250:
- valid value for tx phase shift and rx phase shift is 0 to 7.
 @@ -79,8 +80,8 @@ Example:
 broken-cd;
 fifo-depth = 0x80;
 card-detect-delay = 200;
 -   samsung,dw-mshc-ciu-div = 3;
 -   samsung,dw-mshc-sdr-timing = 2 3;
 -   samsung,dw-mshc-ddr-timing = 1 2;
 +   samsung,dw-mshc-sdr-timing = 2 3 3;
 +   samsung,dw-mshc-ddr-timing = 1 2 3;
 +   samsung,dw-mshc-hs200-timing = 0 2 3;

You are breaking backward compatibility here.  If your change is
merged then all old boards will instantly break.  Since the dts and
code changes will likely be merged through different trees you'll end
up with a bunch of broken trees until everything is merged together.
Even if you don't subscribe to the stable bindings theory this is not
acceptable.

-Doug
--
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 1/3] ARM: dts: Add SPI flash node for Peach boards

[Doug Anderson]

Javier,

On Wed, Nov 19, 2014 at 2:07 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 Hello Doug,

 Thanks for your feedback.

 On 11/18/2014 06:50 PM, Doug Anderson wrote:
 This is common practice in the Chrome OS tree, but we've gotten
 pushback from upstream questioning about whether spidev is really a
 physical device.  See:

 http://www.spinics.net/lists/linux-samsung-soc/msg29563.html


 I see, I thought that it was a common practice in the mainline kernel
 too since I saw that many board DTS currently have a spidev node:

 $ git grep 'compatible = spidev' arch/arm/boot/dts/ | wc -l
 19


 I don't really have an answer for something better to do here but I
 figured I'd at least bring up the point.


 I wonder how the spidev user-space interface is supposed to be used
 when booting with Device Trees.

OK.  Please don't take my comments as a NAK on this patch.  I should
have done the same grep myself before sending--sorry.  I just
remembered the old conversation and looked for that instead.

If the convention is to use spidev like this then I guess we're OK.
I do wish it was a little more like i2c myself where you could get a
direct access interface no matter what driver was bound underneath
(and also if no drivers were bound underneath).  ...but I could just
be naive.  ;)

-Doug
--
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 1/3] ARM: dts: Add SPI flash node for Peach boards

[Doug Anderson]

Javier,

On Mon, Nov 17, 2014 at 9:43 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 +spi_1 {
 +   status = okay;
 +   samsung,spi-src-clk = 0;
 +   num-cs = 1;
 +   cs-gpios = gpa2 5 0;
 +
 +   spidev@0 {
 +   compatible = spidev;

This is common practice in the Chrome OS tree, but we've gotten
pushback from upstream questioning about whether spidev is really a
physical device.  See:

http://www.spinics.net/lists/linux-samsung-soc/msg29563.html


I don't really have an answer for something better to do here but I
figured I'd at least bring up the point.

-Doug
--
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] clocksource: exynos_mct: fix exynos4_mct_write

[Doug Anderson]

Tobias,

On Tue, Oct 21, 2014 at 6:37 PM, Tobias Jakobi
tjak...@math.uni-bielefeld.de wrote:
 EXYNOS4_MCT_L_MASK is defined as 0xff00, so applying this bitmask
 produces a number outside the range 0x00 to 0xff, which always results
 in execution of the default switch statement.

 Obviously this is wrong and git history shows that the bitmask inversion
 was incorrectly set during a refactoring of the MCT code.

 Fix this by putting the inversion at the correct position again.

 Reported-by: GP Orcullo kinsama...@gmail.com
 Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
 ---
  drivers/clocksource/exynos_mct.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

Wow, the old code was pretty broken.  Nice find!  Was this found by
code inspection / analysis or were you seeing some actual bug?  I
think it was broken back in March 2013 in (a1ba7a7 ARM: EXYNOS: add a
register base address variable in mct controller driver), so 1.5
years.  The broken code has been running for a long time, but that
doesn't mean that there isn't a subtle issue...

In any case, it seems like we should take this fix, assuming someone
has tested it well.

Reviewed-by: Doug Anderson diand...@chromium.org
--
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 2/2] ARM: EXYNOS: Call regulator core suspend prepare and finish functions

[Doug Anderson]

Javier,

On Thu, Oct 16, 2014 at 3:13 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 The regulator framework has a set of helpers functions to be used when
 the system is entering and leaving from suspend but these are not called
 on Exynos platforms. This means that the .set_suspend_* function handlers
 defined by regulator drivers are not called when the system is suspended.

 Suggested-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/mach-exynos/suspend.c | 18 ++
  1 file changed, 18 insertions(+)

 diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
 index cc8d237..ee9a8e0 100644
 --- a/arch/arm/mach-exynos/suspend.c
 +++ b/arch/arm/mach-exynos/suspend.c
 @@ -20,6 +20,7 @@
  #include linux/io.h
  #include linux/irqchip/arm-gic.h
  #include linux/err.h
 +#include linux/regulator/machine.h

  #include asm/cacheflush.h
  #include asm/hardware/cache-l2x0.h
 @@ -443,6 +444,22 @@ static int exynos_suspend_enter(suspend_state_t state)

  static int exynos_suspend_prepare(void)
  {
 +   int ret;
 +
 +   /*
 +* REVISIT: It would be better if struct platform_suspend_ops
 +* .prepare handler get the suspend_state_t as a parameter to
 +* avoid hard-coding the suspend to mem state. It's safe to do
 +* it now only because the suspend_valid_only_mem function is
 +* used as the .valid callback used to check if a given state
 +* is supported by the platform anyways.
 +*/
 +   ret = regulator_suspend_prepare(PM_SUSPEND_MEM);
 +   if (ret) {
 +   pr_err(Failed to prepare regulators for system suspend\n);
 +   return ret;
 +   }
 +
 s3c_pm_check_prepare();

 return 0;
 @@ -451,6 +468,7 @@ static int exynos_suspend_prepare(void)
  static void exynos_suspend_finish(void)
  {
 s3c_pm_check_cleanup();
 +   regulator_suspend_finish();

It turns out that regulator_suspend_finish() actually returns an error
code.  Could you print a warning if you see it?

Other than that, feel free to add my Reviewed-by.  Thanks!

-Doug
--
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 2/2] ARM: EXYNOS: Call regulator core suspend prepare and finish functions

[Doug Anderson]

Javier,

On Mon, Oct 20, 2014 at 9:58 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 It turns out that regulator_suspend_finish() actually returns an error
 code.  Could you print a warning if you see it?


 Yes, I noticed this when looking at Chris patch for Rockchip but didn't 
 re-spin
 because I'm not sure anymore if this is the right solution. I mean, if is
 correct to add the same calls on every platform or if the regulator suspend
 prepare and finish functions should be called from the suspend core instead.

 For example calling regulator_suspend_prepare() from 
 platform_suspend_prepare()
 [0] will have the advantage of passing the correct suspend_state_t state 
 instead
 of hard-coding PM_SUSPEND_MEM and will make the regulator suspend states to 
 work
 on all platforms.

Yes.  If we can get this added to the core that would be better.

I guess I was just trying to follow the suggestion that was in the
regulator code:
http://lxr.free-electrons.com/source/drivers/regulator/core.c#L3699
that says This will usually be called by machine suspend code prior
to supending.

-Doug
--
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 v3 1/2] Revert mfd: sec-core: Prepare regulators for suspend state to reduce power-consumption

[Doug Anderson]

Javier,

On Mon, Oct 20, 2014 at 2:05 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 This reverts commit b7cde7078d2344073c310aa65fc2b0a845d2cb5b
 (mfd: sec-core: Prepare regulators for suspend state to reduce 
 power-consumption)

 Commit b7cde7078d23 called regulator_suspend_prepare() to prepare the
 regulators for a suspend state. But it did from the device pm suspend
 handler while the regulator suspend prepare function iterates over all
 regulators and not only the one managed by this device so it doesn't
 seems to be correct to call it from within a device driver.

 It is better to call the regulator suspend prepare/finish functions
 from platform code instead so this patch reverts the mentioned commit.

 Suggested-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

Reviewed-by: Doug Anderson diand...@chromium.org
--
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 1/1] ARM: EXYNOS: Call regulator core suspend prepare and finish functions

[Doug Anderson]

Javier,

On Wed, Oct 15, 2014 at 5:01 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 The regulator framework has a set of helpers functions to be used when
 the system is entering and leaving from suspend but these are not called
 on Exynos platforms. This means that the .set_suspend_* function handlers
 defined in regulator drivers are never called when the system is suspended.

 Suggested-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

Could you also add a patch to your series ripping out the call in
drivers/mfd/sec-core.c since it doesn't belong there.  If you don't
rip that out then it will be called twice on systems with that
regulator.


 ---
  arch/arm/mach-exynos/suspend.c | 16 
  1 file changed, 16 insertions(+)

 diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
 index f5d9773..5b9c551 100644
 --- a/arch/arm/mach-exynos/suspend.c
 +++ b/arch/arm/mach-exynos/suspend.c
 @@ -20,6 +20,7 @@
  #include linux/io.h
  #include linux/irqchip/arm-gic.h
  #include linux/err.h
 +#include linux/regulator/machine.h

  #include asm/cacheflush.h
  #include asm/hardware/cache-l2x0.h
 @@ -270,14 +271,29 @@ static int exynos_suspend_enter(suspend_state_t state)

  static int exynos_suspend_prepare(void)
  {
 +   int ret;
 +
 s3c_pm_check_prepare();

 +   /*
 +* REVISIT: It would be better if struct platform_suspend_ops
 +* .prepare handler get the suspend_state_t as a parameter to
 +* avoid hard-coding the suspend to mem state. It's safe to do
 +* it only because the suspend_valid_only_mem function is the
 +* .valid callback used to check if a given state is supported
 +* by the platform.
 +*/
 +   ret = regulator_suspend_prepare(PM_SUSPEND_MEM);
 +   if (ret)
 +   pr_info(Failed to prepare regulators for system suspend\n);
 +

nit: can you put this before s3c_pm_check_prepare().  pm_check is
pretty darn broken and I have a feeling that it will eventually be
ripped out (or in the very least ported to not be Samsung-specific and
include all of the suspend volatile crud that we have in the
chromeos-3.8 kernel), but might as well try not to break it further.

Changing the order also has the advantage of making prepare / finish
opposite orders (good!) and handling the fact that you would call
s3c_pm_check_prepare() but not s3c_pm_check_cleanup() if
regulator_suspend_prepare() fails.


 return 0;
  }

  static void exynos_suspend_finish(void)
  {
 s3c_pm_check_cleanup();
 +   regulator_suspend_finish();
  }

  static const struct platform_suspend_ops exynos_suspend_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] ARM: dts: fix MMC2 regulators for Exynos5420 Arndale Octa board

[Doug Anderson]

Hi,

On Wed, Oct 8, 2014 at 8:20 AM, Arnd Bergmann a...@arndb.de wrote:
 Why does it cause a regression though? Does this mean you are breaking
 any boot with an old DT file and a new kernel? That would be very
 bad, the driver is supposed to keep working with an existing dtb.

The old dts file specified completely the wrong regulator.  It
happened that the old code didn't really care, but when the code was
fixed to care then things broke.  If we need to keep old dts files
working then the most sensible place to do it would be in a fixup old
broken device trees stage somewhere in kernel boot.

-Doug
--
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: fix MMC2 regulators for Exynos5420 Arndale Octa board

[Doug Anderson]

Bartlomiej,

On Thu, Oct 2, 2014 at 10:24 AM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:

 Hi,

 On Thursday, October 02, 2014 09:45:41 AM Doug Anderson wrote:
 Bartiomiej

 On Thu, Oct 2, 2014 at 9:39 AM, Bartlomiej Zolnierkiewicz
 b.zolnier...@samsung.com wrote:
  On Thursday, October 02, 2014 09:19:08 AM Doug Anderson wrote:
  Bartiomiej,
 
  On Thu, Oct 2, 2014 at 9:10 AM, Bartlomiej Zolnierkiewicz
  b.zolnier...@samsung.com wrote:
   Regulators for MMC2 (SD card) are PVDD_TFLASH_2V8 (LDO19) for vmmc
   and PVDD_APIO_MMCOFF_2V8 (LDO13) for vqmmc.  Currently the device
   tree entry for MMC2 uses PVDD_PRE_1V8 (LDO10) for vmmc and vqmmc is
   not specified.  Fix it.
  
   Without this patch:
   - mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
 patch causes a SD card detection to fail
   - mmc: dw_mmc: Support voltage changes patch causes a boot hang
  
   This patch fixes both above problems.
  
   Suggested-by: Doug Anderson diand...@google.com
   Cc: Yuvaraj Kumar C D yuvaraj...@samsung.com
   Cc: Ulf Hansson ulf.hans...@linaro.org
   Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
   Acked-by: Kyungmin Park kyungmin.p...@samsung.com
   ---
arch/arm/boot/dts/exynos5420-arndale-octa.dts |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
  
   Index: b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
   ===
   --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 2014-10-02 
   15:44:53.014826886 +0200
   +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts 2014-10-02 
   17:35:24.110600398 +0200
   @@ -74,7 +74,8 @@
   samsung,dw-mshc-ddr-timing = 1 2;
   pinctrl-names = default;
   pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
   -   vmmc-supply = ldo10_reg;
   +   vmmc-supply = ldo19_reg;
   +   vqmmc-supply = ldo13_reg;
 
  This looks right to me.  ...but I notice that ldo13 and ldo19 are not
  always-on in the DTS.  Are you sure card detect works for you if you
  eject your card and try to put it back in?
 
  ...eventually the always-on won't be needed, but for now I think it 
  is...
 
  Card detection works fine without always-on.

 That's weird.

 1. In the schematics I see XMMC2CDN has an external pullup to 
 PVDD_TFLASH_2V8.

 2. The internal pullup should (I think) be to VDDQ_MMC2 which is
 PVDD_APIO_MMCOFF_2V8.

 3. In (51da224 mmc: dw_mmc: use mmc_regulator_get_supply to handle
 regulators) we should be turning off both regulators in
 MMC_POWER_OFF.

 4. If I understand correctly MMC_POWER_OFF is called when the card is
 ejected, which means that both regulators should be off when the card
 is ejected.

 5. I don't think card detect can work if neither regulator is powered.


 One of the above points must be wrong.  Any idea which one?  Can you
 check to see if MMC_POWER_OFF is called for you when the card is
 ejected?  Can you check to see if these regulators are off?

 MMC_POWER_OFF is called on card removal and both regulators get disabled
 (I have verified that they are really off with regulator_is_enabled() which
 returns 1 before and 0 after disabling regulator).  It seems that 5. is
 wrong?

This really doesn't make a lot of sense to me, so I'm still kinda
confused.  If you want to call it good then that's your (and Ulf's)
decision, but it's the kind of thing that would keep me up at night.
How can this pin be high if all the regulators pulling it up are off?
Is there a current leak somewhere and that's why it's working?

How this is supposed to work (as I understand it):

1. When no card is inserted then this pin is supposed to be pulled up
to VDDQ_MMC2.  That could be either an internal or an external pullup.
It should be pulled up to VDDQ_MMC2 (as opposed to any other voltage)
since the exynos manual documents that this pin lives in the VDDQ_MMC2
io domain.  Note that it could be pulled up externally to a different
supply than the one going to VDDQ_MMC2, but for correctness it should
be the same voltage.

2. When a card is inserted, the pin will be grounded (AKA this is an
open drain pin).


With your patch, can you probe the pin and see if card detect is high
when all the regulators are off?  Any idea how it gets high?  If you
turn off the internal pullup is it still high?


-Doug
--
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: fix MMC2 regulators for Exynos5420 Arndale Octa board

[Doug Anderson]

Bartiomiej,

On Thu, Oct 2, 2014 at 9:10 AM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:
 Regulators for MMC2 (SD card) are PVDD_TFLASH_2V8 (LDO19) for vmmc
 and PVDD_APIO_MMCOFF_2V8 (LDO13) for vqmmc.  Currently the device
 tree entry for MMC2 uses PVDD_PRE_1V8 (LDO10) for vmmc and vqmmc is
 not specified.  Fix it.

 Without this patch:
 - mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
   patch causes a SD card detection to fail
 - mmc: dw_mmc: Support voltage changes patch causes a boot hang

 This patch fixes both above problems.

 Suggested-by: Doug Anderson diand...@google.com
 Cc: Yuvaraj Kumar C D yuvaraj...@samsung.com
 Cc: Ulf Hansson ulf.hans...@linaro.org
 Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/boot/dts/exynos5420-arndale-octa.dts |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 Index: b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
 ===
 --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 2014-10-02 
 15:44:53.014826886 +0200
 +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts 2014-10-02 
 17:35:24.110600398 +0200
 @@ -74,7 +74,8 @@
 samsung,dw-mshc-ddr-timing = 1 2;
 pinctrl-names = default;
 pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
 -   vmmc-supply = ldo10_reg;
 +   vmmc-supply = ldo19_reg;
 +   vqmmc-supply = ldo13_reg;

This looks right to me.  ...but I notice that ldo13 and ldo19 are not
always-on in the DTS.  Are you sure card detect works for you if you
eject your card and try to put it back in?

...eventually the always-on won't be needed, but for now I think it is...

-Doug
--
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: fix MMC2 regulators for Exynos5420 Arndale Octa board

[Doug Anderson]

Bartiomiej

On Thu, Oct 2, 2014 at 9:39 AM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:
 On Thursday, October 02, 2014 09:19:08 AM Doug Anderson wrote:
 Bartiomiej,

 On Thu, Oct 2, 2014 at 9:10 AM, Bartlomiej Zolnierkiewicz
 b.zolnier...@samsung.com wrote:
  Regulators for MMC2 (SD card) are PVDD_TFLASH_2V8 (LDO19) for vmmc
  and PVDD_APIO_MMCOFF_2V8 (LDO13) for vqmmc.  Currently the device
  tree entry for MMC2 uses PVDD_PRE_1V8 (LDO10) for vmmc and vqmmc is
  not specified.  Fix it.
 
  Without this patch:
  - mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
patch causes a SD card detection to fail
  - mmc: dw_mmc: Support voltage changes patch causes a boot hang
 
  This patch fixes both above problems.
 
  Suggested-by: Doug Anderson diand...@google.com
  Cc: Yuvaraj Kumar C D yuvaraj...@samsung.com
  Cc: Ulf Hansson ulf.hans...@linaro.org
  Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
  Acked-by: Kyungmin Park kyungmin.p...@samsung.com
  ---
   arch/arm/boot/dts/exynos5420-arndale-octa.dts |3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)
 
  Index: b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
  ===
  --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 2014-10-02 
  15:44:53.014826886 +0200
  +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts 2014-10-02 
  17:35:24.110600398 +0200
  @@ -74,7 +74,8 @@
  samsung,dw-mshc-ddr-timing = 1 2;
  pinctrl-names = default;
  pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
  -   vmmc-supply = ldo10_reg;
  +   vmmc-supply = ldo19_reg;
  +   vqmmc-supply = ldo13_reg;

 This looks right to me.  ...but I notice that ldo13 and ldo19 are not
 always-on in the DTS.  Are you sure card detect works for you if you
 eject your card and try to put it back in?

 ...eventually the always-on won't be needed, but for now I think it is...

 Card detection works fine without always-on.

That's weird.

1. In the schematics I see XMMC2CDN has an external pullup to PVDD_TFLASH_2V8.

2. The internal pullup should (I think) be to VDDQ_MMC2 which is
PVDD_APIO_MMCOFF_2V8.

3. In (51da224 mmc: dw_mmc: use mmc_regulator_get_supply to handle
regulators) we should be turning off both regulators in
MMC_POWER_OFF.

4. If I understand correctly MMC_POWER_OFF is called when the card is
ejected, which means that both regulators should be off when the card
is ejected.

5. I don't think card detect can work if neither regulator is powered.


One of the above points must be wrong.  Any idea which one?  Can you
check to see if MMC_POWER_OFF is called for you when the card is
ejected?  Can you check to see if these regulators are off?


-Doug
--
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 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators

[Doug Anderson]

Hi,

On Wed, Oct 1, 2014 at 6:06 AM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:

 Hi,

 On Tuesday, September 30, 2014 10:22:34 AM Doug Anderson wrote:
 Bartlomiej

 On Mon, Sep 29, 2014 at 5:31 AM, Bartlomiej Zolnierkiewicz
 b.zolnier...@samsung.com wrote:
 
  Hi,
 
  On Friday, August 29, 2014 01:34:44 PM Ulf Hansson wrote:
  On 22 August 2014 15:47, Yuvaraj Kumar C D yuvaraj...@gmail.com wrote:
   This patch makes use of mmc_regulator_get_supply() to handle
   the vmmc and vqmmc regulators.Also it moves the code handling
   the these regulators to dw_mci_set_ios().It turned on the vmmc
   and vqmmc during MMC_POWER_UP and MMC_POWER_ON,and turned off
   during MMC_POWER_OFF.
  
   Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
 
  Thanks! Applied for next.
 
  Unfortunately this patch breaks mmc1 card (Kingston 32GB micro SDHC)
  detection on Exynos5420 Arndale Octa for me:
 
  [   10.797979] dwmmc_exynos 1222.mmc: no support for card's volts
  [   10.797998] mmc1: error -22 whilst initialising SD card
 
  Without the patch:
 
  [   10.866926] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 
  5000Hz, actual 5000HZ div = 0)
  [   10.866977] mmc1: new high speed SDHC card at address 1234
  [   10.868730] mmcblk1: mmc1:1234 SA32G 29.3 GiB
  [   10.915054]  mmcblk1: p1 p2 p3
 
  The config is attached (exynos_defconfig doesn't work correctly for
  this board yet).

 Yup, this is an expected behavior, unfortunately.  This was talked
 about extensively during the review of this patch series.

 Do you mean that a patch with a known regression has been merged
 into next branch of mmc tree?  It would be quite sad if it would be
 true.

...so looking at your dts file, it looks like this _isn't_ your
problem.  Your vmmc regulator is listed as always on, so I believe
that you're OK.  Your regulator probably _shouldn't_ be always on
(it prevents power cycling the SD card) but right now it's good that
it is...

If any board has a vmmc that is not listed as always on then it
would regress with the first two patches applied (and without the
3rd), but there are none that I personally know of that do.
--
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 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators

[Doug Anderson]

Hi,

On Wed, Oct 1, 2014 at 7:00 AM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:

 Hi,

 On Wednesday, October 01, 2014 12:47:52 AM YUVARAJ CD wrote:

 Since I am out of station, i dont have an access to my work set up.
 Can you send me the dts entries of sd crad and their corresponding regulator 
 entries?

 From arch/arm/boot/dts/exynos5420-arndale-octa.dts:

 ...
 mmc@1220 {
 status = okay;
 broken-cd;
 supports-highspeed;
 card-detect-delay = 200;
 samsung,dw-mshc-ciu-div = 3;
 samsung,dw-mshc-sdr-timing = 0 4;
 samsung,dw-mshc-ddr-timing = 0 2;
 pinctrl-names = default;
 pinctrl-0 = sd0_clk sd0_cmd sd0_bus4 sd0_bus8;
 vmmc-supply = ldo10_reg;

 slot@0 {
 reg = 0;
 bus-width = 8;
 };
 };

 mmc@1222 {
 status = okay;
 supports-highspeed;
 card-detect-delay = 200;
 samsung,dw-mshc-ciu-div = 3;
 samsung,dw-mshc-sdr-timing = 2 3;
 samsung,dw-mshc-ddr-timing = 1 2;
 pinctrl-names = default;
 pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
 vmmc-supply = ldo10_reg;

 slot@0 {
 reg = 0;
 bus-width = 4;
 };
 };
 ...
 ldo10_reg: LDO10 {
 regulator-name = PVDD_PRE_1V8;
 regulator-min-microvolt = 180;
 regulator-max-microvolt = 180;
 regulator-always-on;
 };

I don't have schematics for Arndale Octa, but the above is really
fishy.  vmmc shouldn't be 1.8V.  That's the general power signal to
MMC and should be 2.7V - 3.6V.  vqmmc could be 1.8V in certain
situations, but my understanding is that for maximum compatibility it
should at least start out identical to vmmc (and later go down to
1.7V - 1.95V).

My first thought would be to just remove the vmmc-supply from your
DTS.  I think we could land that and pick it back easily.  That will
get you something working and won't introduce any regressions because:
1. MMC core will give you a dummy regulator
2. The code will default to assuming that vmmc is 3.3V, which is what
it used to do anyway.
3. The only referenced regulator is always on anyway.

Separately you could specify a proper vmmc and maybe even a vqmmc.

On SMDK5420 I see this for the SD card (mmc2):
* vmmc should be VDD_SD_2V8.  From LDO19.
* vqmmc should be VDDQ_MMC2_AP.  From LDO13.

OK, I dug up the Arndale schematics.  For mmc2:
* vmmc should be PVDD_TFLASH_2V8.  That's LDO19.
* vqmmc (hooked up to VDDQ_MMC2): PVDD_APIO_MMCOFF_2V8.  LDO13 just like SMDK.

...sadly it looks like Anrdale has a schematics problem that prevents
you from doing UHS.  I see that the data lines are pulled up to
PVDD_TFLASH_2V8 (vmmc), not pulled up to PVDD_APIO_MMCOFF_2V8 (vqmmc).
I think that means that if you ever lower vqmmc to 1.8V (as needed for
UHS) then you'll still be pulling up to 2.8V.  That's not good.  You
should probably make sure that both LDO13 and LDO19 are listed as
being exactly 2.8V.


Anyway, the above has (obviously) not been tested and is just based on
a casual browsing of schematics.  Please let me know how it goes.



-Doug
--
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 v7] mfd: syscon: Decouple syscon interface from platform devices

[Doug Anderson]

Pankaj,

On Tue, Sep 30, 2014 at 1:35 AM, Pankaj Dubey pankaj.du...@samsung.com wrote:
 Currently a syscon entity can be only registered directly through a
 platform device that binds to a dedicated syscon driver. However in
 certain use cases it is desirable to make a device used with another
 driver a syscon interface provider.

 For example, certain SoCs (e.g. Exynos) contain system controller
 blocks which perform various functions such as power domain control,
 CPU power management, low power mode control, but in addition contain
 certain IP integration glue, such as various signal masks,
 coprocessor power control, etc. In such case, there is a need to have
 a dedicated driver for such system controller but also share registers
 with other drivers. The latter is where the syscon interface is helpful.

 In case of DT based platforms, this patch decouples syscon object from
 syscon platform driver, and allows to create syscon objects first time
 when it is required by calling of syscon_regmap_lookup_by APIs and keep
 a list of such syscon objects along with syscon provider device_nodes
 and regmap handles.

 For non-DT based platforms, this patch keeps syscon platform driver
 structure so that syscon can be probed and such non-DT based drivers
 can use syscon_regmap_lookup_by_pdev API and access regmap handles.
 Once all users of syscon_regmap_lookup_by_pdev migrated to DT based,
 we can completely remove platform driver of syscon, and keep only helper
 functions to get regmap handles.

 Suggested-by: Arnd Bergmann a...@arndb.de
 Suggested-by: Tomasz Figa tomasz.f...@gmail.com
 Tested-by: Vivek Gautam gautam.vi...@samsung.com
 Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 Reviewed-by: Arnd Bergmann a...@arndb.de
 Tested-by: Heiko Stuebner he...@sntech.de
 Reviewed-by: Heiko Stuebner he...@sntech.de
 ---
 Patch v6 and related discussions can be found here [1].

 Change since v5:
  - Addressed review comments from Heiko Stuebner.
  - Updated commit description.
  - Including Arnd's and Heiko's Reviewed-by.

 Change since v5:
  - Dropping creation of dummy platform device in of_syscon_register.
  - As we are changing syscon to decouple from platform_device, creation of
dummy platform_device does not look good option, and as suggested by Arnd,
I made another attempt so that regmap_mmio_init API should work with NULL
dev pointer itself. Since regmap needs to know about Syscon device node
properties so let's parse device node of syscon in syscon itself for any
such properties and using regmap_config parameter pass all such information
to regmap. Other concern of crashes due to NULL dev pointer in regmap 
 already
addressed in separate patches of regmap. Please see [2] and [3].

 Changes since v4:
  - Addressed Tomasz Figa's comments for v4.
  - Added error handing in of_syscon_register function.
  - Using devm_regmap_init_mmio instead of regmap_init_mmio.

 Changes since v3:
  - Addressed Arnd's comment for v2.
  - Updated of_syscon_register for adding dev pointer in regmap_init_mmio.
  - For early users created dummy platform device.

 Changes since v2:
  - Added back platform device support from syscon, with one change that
syscon will not be probed for DT based platform.
  - Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
users of syscon will not be broken.
  - Removed unwanted change in syscon.h.
  - Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
Arnd Bergmann.
  - Added Tested-by of Vivek Gautam for testing on Exynos platform.

 Changes since v1:
  - Removed of_syscon_unregister function.
  - Modified of_syscon_register function and it will be used by syscon.c
to create syscon objects whenever required.
  - Removed platform device support from syscon.
  - Removed syscon_regmap_lookup_by_pdevname API support.
  - As there are significant changes w.r.t patchset v1, I am taking over
author for this patchset from Tomasz Figa.

 [1]: https://lkml.org/lkml/2014/9/29/99
 [2]: https://lkml.org/lkml/2014/9/18/130
 [3]: https://lkml.org/lkml/2014/9/27/2
  drivers/mfd/syscon.c |   96 
 ++
  1 file changed, 74 insertions(+), 22 deletions(-)

You probably already have enough tags, but just in case.  ;)  On an
rk3288-based system (this patch backported to 3.14):

Tested-by: Doug Anderson diand...@chromium.org
--
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 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators

[Doug Anderson]

Bartlomiej

On Mon, Sep 29, 2014 at 5:31 AM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:

 Hi,

 On Friday, August 29, 2014 01:34:44 PM Ulf Hansson wrote:
 On 22 August 2014 15:47, Yuvaraj Kumar C D yuvaraj...@gmail.com wrote:
  This patch makes use of mmc_regulator_get_supply() to handle
  the vmmc and vqmmc regulators.Also it moves the code handling
  the these regulators to dw_mci_set_ios().It turned on the vmmc
  and vqmmc during MMC_POWER_UP and MMC_POWER_ON,and turned off
  during MMC_POWER_OFF.
 
  Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com

 Thanks! Applied for next.

 Unfortunately this patch breaks mmc1 card (Kingston 32GB micro SDHC)
 detection on Exynos5420 Arndale Octa for me:

 [   10.797979] dwmmc_exynos 1222.mmc: no support for card's volts
 [   10.797998] mmc1: error -22 whilst initialising SD card

 Without the patch:

 [   10.866926] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 
 5000Hz, actual 5000HZ div = 0)
 [   10.866977] mmc1: new high speed SDHC card at address 1234
 [   10.868730] mmcblk1: mmc1:1234 SA32G 29.3 GiB
 [   10.915054]  mmcblk1: p1 p2 p3

 The config is attached (exynos_defconfig doesn't work correctly for
 this board yet).

Yup, this is an expected behavior, unfortunately.  This was talked
about extensively during the review of this patch series.

I believe that patch #3 in Yuvaraj's series would fix your problem.
Specifically https://patchwork.kernel.org/patch/4763891/.


The current summary of this issue is (Ulf, please correct me if I got
anything wrong):

1. If nothing else, Yuvaraj's patch should probably be split in two.
One half should be the MMC core half that I originally sent Yuvaraj.
I just rebased and re-uploaed it at
https://chromium-review.googlesource.com/220560 in case you're
curious.  The second half should be the dw_mmc piece that Yuvaraj
wrote.

2. Ulf has indicated that he thinks that the MMC core change (and thus
Yuvaraj's patch) is ugly and not necessary.  He advocates instead
using the MMC_CAP_NEEDS_POLL on all affected platforms.  That means
we'll turn on the power every second, check for the card, then turn
off power.

3. I'm still of the opinion that the MMC core change isn't _that_
ugly.  Given that there are a large number of systems affected (across
at least two SoC vendors) and that it would be nice if those systems
didn't have to poll, I'd still be happy if the MMC core change could
go in.  ...but I'm a pragmatist and know that the polling isn't
_terrible_, so if that's the way we need to go then so be it.

--

My understanding was that Yuvaraj was going to spin his patch to use a
similar type of scheme to autodetect affected SoCs (looking for SoCs
known to have this problem where the platform data shows them using
the built-in card detect) and then enable MMC_CAP_NEEDS_POLL.  I
haven't seen a patch from him, so maybe you could post this up?

Note: the reason why exynos5250-snow and some other boards aren't
affected yet is that the regulator is simply not specified in the
device tree (it's just left always on).

---

-Doug
--
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 v10 0/6] Add Maxim 77802 RTC support

[Doug Anderson]

Javier,

On Fri, Sep 19, 2014 at 3:26 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 Hello Andrew,

 This series add support for the Real Time clock present in
 the Maxim 77802 Power Managment IC. The version number is
 quite high because it previously was part of a bigger series
 [0] that aimed to add support for all the devices in the
 max77802 PMIC. But now that the max77802 dependencies were
 already merged for 3.17, the series were split but I kept
 the version numbering.

 While working on the max77802 rtc support a lot of feedback
 was given and the issues pointed out also apply to a driver
 for a similar PMIC RTC (max77686). So patches 01/06 to 05/06
 in the series are cleanups for the max77686 driver and patch
 06/06 adds the support for the max77802 RTC.

 This version address the issues pointed out on the previous
 version [1] and changelog are present on each patch when is
 applicable.

 The series were tested on an Exynos5250 Snow (max77686) and
 Exynos5420 Peach Pit (max77802) machines and applies cleanly
 to both 3.17-rc1 and today's linux-next (20140919).

 NOTE: The patches from the previous version [1] were already
 present in the -mm tree [2] so I didn't know if I should had
 sent this as a delta or as a new revision. I decided to do
 the later but please let me know if you expected the former.

My records show that Andrew has already accepted most of these.  They
may not show up in linuxnext yet, but that doesn't mean Andrew hasn't
taken them (I think).


 Doug Anderson (1):
   rtc: max77686: Allow the max77686 rtc to wakeup the system


http://ozlabs.org/~akpm/mmots/broken-out/rtc-max77686-allow-the-max77686-rtc-to-wakeup-the-system.patch

 Javier Martinez Canillas (5):
   rtc: max77686: Remove dead code for SMPL and WTSR.


http://ozlabs.org/~akpm/mmots/broken-out/rtc-max77686-remove-dead-code-for-smpl-and-wtsr.patch

   rtc: max77686: Fail to probe if no RTC regmap irqchip is set


http://ozlabs.org/~akpm/mmots/broken-out/rtc-max77686-fail-to-probe-if-no-rtc-regmap-irqchip-is-set.patch

   rtc: max77686: Remove unneded info log


http://ozlabs.org/~akpm/mmots/broken-out/rtc-max77686-remove-unneded-info-log.patch

   rtc: max77686: Use ffs() to calculate tm_wday

This one hasn't been accepted...

   rtc: Add driver for Maxim 77802 PMIC Real-Time-Clock


http://ozlabs.org/~akpm/mmots/broken-out/rtc-add-driver-for-maxim-77802-pmic-real-time-clock.patch


-Doug
--
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 1/2] ARM: dts: Add rtc_src clk for s3c-rtc on exynos Peach boards

[Doug Anderson]

Javier,

On Wed, Sep 17, 2014 at 4:50 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 commit 546b117fdf17 (rtc: s3c: add support for RTC of Exynos3250 SoC)
 added an rtc_src DT property for the Samsung's S3C Real Time Clock
 controller that specifies the 32.768 kHz clock that uses the RTC as its
 source clock. In the case of the Peach Pit and Pi machines, the Maxim
 77802 32kHz AP clock is used as the source clock.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/exynos5420-peach-pit.dts | 5 -
  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 5 -
  2 files changed, 8 insertions(+), 2 deletions(-)

Reviewed-by: Doug Anderson diand...@chromium.org
--
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] ARM: dts: Add rtc_src clk for s3c-rtc on exynos5250-snow

[Doug Anderson]

Hi,

On Wed, Sep 17, 2014 at 4:50 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 commit 546b117fdf17 (rtc: s3c: add support for RTC of Exynos3250 SoC)
 added an rtc_src DT property for the Samsung's S3C Real Time Clock
 controller that specifies the 32.768 kHz clock that uses the RTC as its
 source clock. In the case of the Exynos5250 based Snow board, the Maxim
 77686 32kHz AP clock is used as the source clock.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/exynos5250-snow.dts | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
 b/arch/arm/boot/dts/exynos5250-snow.dts
 index e51fcef..56eec56 100644
 --- a/arch/arm/boot/dts/exynos5250-snow.dts
 +++ b/arch/arm/boot/dts/exynos5250-snow.dts
 @@ -10,6 +10,7 @@

  /dts-v1/;
  #include dt-bindings/gpio/gpio.h
 +#include dt-bindings/clock/maxim,max77686.h
  #include exynos5250.dtsi

  / {
 @@ -29,6 +30,8 @@

 rtc@101E {
 status = okay;
 +   clocks = clock CLK_RTC, max77686 MAX77686_CLK_AP;
 +   clock-names = rtc, rtc_src;

Wait, seriously?  Snow is still using the rtc@101E syntax?
Whatever happened to the series that Andreas worked so hard on,
including https://patchwork.kernel.org/patch/4664801/?

Kukjin: Andreas's patch series was Reviewed long ago I think and by
now I'd imagine it's got some conflicts due to it not having been
applied in a timely fashion.  Perhaps you could fix it up for Andreas
(since he's already rebased it several times) and land it?

If I had to guess, outstanding from Andreas's series (patchwork IDs listed):

4751131 New  [v7] ARM: dts: Prepare node labels for exynos5250
4664801 New  [v6,04/10] ARM: dts: Clean up exynos5250-snow
4664771 New  [v6,05/10] ARM: dts: Fill in bootargs for exynos5250-snow
4664731 New  [v6,06/10] ARM: dts: Clean up exynos5250-smdk5250
4664751 New  [v6,07/10] ARM: dts: Clean up exynos5250-arndale
4664711 New  [v6,08/10] ARM: dts: Fix apparent GPIO typo in
exynos5250-arndale
4664681 New  [v6,09/10] ARM: dts: Simplify USB3503 on exynos5250-arndale
4664691 New  [v6,10/10] ARM: dts: Add exynos5250-spring device tree


 };

 pinctrl@1140 {
 @@ -350,7 +353,7 @@
 samsung,i2c-sda-delay = 100;
 samsung,i2c-max-bus-freq = 378000;

 -   max77686@09 {
 +   max77686: max77686@09 {
 compatible = maxim,max77686;
 interrupt-parent = gpx3;
 interrupts = 2 0;

In any case, there's nothing wrong with Javier's patch other than the
fact that it will eventually need to get merged with Andreas's, so:

Reviewed-by: Doug Anderson diand...@chromium.org
--
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 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC

[Doug Anderson]

Daniel,

On Wed, Sep 17, 2014 at 9:49 AM, Daniel Drake dr...@endlessm.com wrote:
 On Tue, Sep 16, 2014 at 4:15 PM, Doug Anderson diand...@chromium.org wrote:
 NOTE: I don't think that the builtin RTC is terribly important for any
 exynos-based Chromebooks that I'm aware of.  We rely on the RTC that's
 part of the Maxim PMIC itself and pretty much ignore the one built-in
 to the exynos.  I think there are some cases it was used (as a
 fallback wakeup source in certain test scripts), but nothing very
 important.

 That's not true for all hardware though, at least the board I'm
 working on now has the SoC RTC as battery-backed and the PMIC one with
 no battery. So in this case at least, the interesting RTC is the SoC
 one.

Yup, I can totally believe that.  My statement was meant only to apply
to the boards I knew about firsthand...

-Doug
--
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 RESEND] ARM: DTS: correct the capability string for mmc0

[Doug Anderson]

Vivek,

On Tue, Sep 16, 2014 at 1:50 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
 From: Naveen Krishna Chatradhi ch.nav...@samsung.com

 MMC capability for HS200 is parsed in mmc/core/host.c as
 dts string mmc-hs200-1_8v.

 This patch corrects the dts string for Exynos5420 based peach-pit
 and Exynos5800 based peach-pi boards.

 Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
 ---

 Hi Kukjin,

 As commented by Doug earlier for this patch, the two patches required
   -- mmc: dw_mmc: Make sure we don't get stuck when we get an error
   -- mmc: dw_mmc: change to use recommended reset procedure
 are now merged in upstream.
 So you can go ahead and pick this change.

  arch/arm/boot/dts/exynos5420-peach-pit.dts |2 +-
  arch/arm/boot/dts/exynos5800-peach-pi.dts  |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Doug Anderson diand...@chromium.org
--
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 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC

[Doug Anderson]

Hi,

On Tue, Sep 16, 2014 at 8:20 AM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
 Hello Daniel,

 On Tue, Sep 16, 2014 at 5:03 PM, Daniel Drake dr...@endlessm.com wrote:
 On Tue, Sep 16, 2014 at 7:48 AM, Javier Martinez Canillas
 jav...@dowhile0.org wrote:
 Clock list for s3c-rtc device:
 - rtc : CLK_RTC of CLK_GATE_IP_PERIR is gate clock for RTC.
 - rtc_src : XrtcXTI is 32.768.kHz source clock for RTC.

 Is this RTC source clock needed for all Exynos SoCs?

 It is at least needed on Exynos4412, which has the XrtcXTI thing
 exactly as you describe. However the very standard setup there is to
 hook it up to the CP clock output of the MAX76686 PMIC. This CP clock
 is on by default, so you can potentially live without that detail
 being present in the DT.


 Thanks for confirming for Exynos4412, I just answered my own email
 saying that I found to be needed on Exynos5420 as well and as you
 said, it was just working because the Maxim clocks were left on by
 default.

 However... one small issue with this setup is that when you enable
 CONFIG_COMMON_CLK_MAX77686, the CP clock gets exposed in Linux's
 common clock framework, and Linux then turns it off because it
 believes it is unused. Then the RTC stops ticking.


 Indeed, this is an issue about relying on default state. We had a
 quite long discussion a couple of weeks ago about simplefb relying on
 clocks and regulators left enabled by the bootloader but once these
 were know to the kernel, the frameworks disable them because were
 unused making simplefb to fail.

 So the rtc_src idea would also be good for Exynos4412. Maybe it would
 make sense to drop the needs_src_clk flag, and simply require/enable
 the src clock whenever it is present in the DT.


 That sounds more sensible to me as well. I wonder what should happen
 in this case with DT backward compatibility though. But as you said,
 the external clock is required and the kernel will disable this clock
 once is know to the CCF since is not used so maybe will be hard to
 maintain DT backward compatibility in this case.

I think you can turn off CONFIG_COMMON_CLK_MAX77686 and then this
clock will be left at whatever the bootloader set it to, right?  Then
there will be no auto-disabling by the CCF and the RTC will work.
That's one argument for making the clock optional.

NOTE: I don't think that the builtin RTC is terribly important for any
exynos-based Chromebooks that I'm aware of.  We rely on the RTC that's
part of the Maxim PMIC itself and pretty much ignore the one built-in
to the exynos.  I think there are some cases it was used (as a
fallback wakeup source in certain test scripts), but nothing very
important.

-Doug
--
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 RESEND v9 1/5] rtc: max77686: Allow the max77686 rtc to wakeup the system

[Doug Anderson]

Hi,

On Fri, Sep 12, 2014 at 1:17 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 From: Doug Anderson diand...@chromium.org

 The max77686 includes an RTC that keeps power during suspend.  It's
 convenient to be able to use it as a wakeup source.

 NOTE: due to wakeup ordering problems this patch alone doesn't work so
 well on exynos5250-snow.  You also need something that brings the i2c
 bus up before the max77686 wakeup runs.

This note made sense when the patch was first submitted, but no longer
does since the i2c change landed.  See:

b19c195 i2c: s3c2410: resume the I2C controller earlier
--
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 RESEND v9 1/5] rtc: max77686: Allow the max77686 rtc to wakeup the system

[Doug Anderson]

Hi,

On Fri, Sep 12, 2014 at 8:54 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 You are right, I completely forgot to check if that actually landed and to
 remove the note in that case...

 Maybe when the set is applied the note can be removed from this patch or do
 you think that I should re-spin the series for that?

This seems like something a maintainer could handle removing, but I
guess it's totally up to the maintainer.  If I were the maintainer I'd
rather remove the note myself then see a whole spin of a 5-part series
just to fix this.  ;)


-Doug
--
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: Unable to boot mainline on snow chromebook since 3.15

[Doug Anderson]

Hi,

On Thu, Sep 11, 2014 at 11:03 AM, Mark Brown broo...@kernel.org wrote:
 On Thu, Sep 11, 2014 at 10:22:32AM +0100, Grant Likely wrote:
 On Wed, 10 Sep 2014 17:57:23 +0100, Mark Brown broo...@kernel.org wrote:

  It's not quite as simple as just disabling PM - for example in the
  clocks case we've also got to worry about what happens with rate changes
  (which is going to get more and more risky as we get smarter about being
  able to push configuration changes back up the tree), regulators have a
  similar thing with voltage changes.  With simple enables and disables we
  have to worry about things like handling users who actively want to
  power things on and and off but may potentially be sharing a resource
  with an undeclared dependency.

 I think we can be okay with the above. This is a best-effort situation
 where we don't want to tear down how firmware has set up the board if
 it can be reasonably assumed that something depends on it (simplefb).
 However, if clocks or regulators are shared with other devices and those
 drivers ask for other settings, then there is simply no recourse. In
 that situation there must be a driver for the video device that takes
 care of any constraints.

 When things break I'm not sure that users are going to understand that
 something that used to work for them was only provided on a best effort
 basis, I think they will expect things to carry on working.

Right.  This is exactly what happened at the start of this thread.
SimpleFB was working only on a best effort basis and then it stopped
working.  I agree that's pretty non-ideal.

-Doug
--
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: Unable to boot mainline on snow chromebook since 3.15

[Doug Anderson]

Will,

On Wed, Sep 10, 2014 at 4:17 AM, Will Deacon will.dea...@arm.com wrote:
 On Mon, Sep 08, 2014 at 03:05:40PM +0100, Javier Martinez Canillas wrote:
 Hello Will,

 Hi Javier,

 Since many folks don't agree that hacking different subsystems is the way
 forward I'll hold the patches and don't post them. The sunxi thread [0]
 already shows how different people have strong opposite positions on the
 correct approach to handle this.

 For now you can just disable the tps65090 PMIC support by not enabling the
 CONFIG_REGULATOR_TPS65090 kconfig symbol on your kernel config. That will 
 give
 you exactly the same behavior that before tps65090 support was added to the
 Snow DT on commit b16be76 (ARM: dts: add tps65090 power regulator for
 exynos5250-snow) which AFAIU was good enough for your workflow.

 Disabling the regulator support gives me my framebuffer back, thanks.

Yay!  Is this good enough to tide you over until DRM support lands?


 I
 then get stuck mounting my root filesystem over sd card because it's
 reported as read-only. The following hack solved the issue, but I'm not
 exactly sure where this regression has come from (whether this is a board
 quirk or pinctrl is really misconfigured).

This is a regression that was introduced by:

9795a84 mmc: dw_mmc: remove dw_mci_of_cd_gpio/wp_gpio()

In exynos5250-cros-common.dtsi you can see that the wp-gpios =
gpc2 1 0; is still listed under the slot node.  Nobody is looking
there anymore.

This is fixed in linux-next by:

aaa25a5 ARM: dts: unuse the slot-node and deprecate the
supports-highspeed for dw-mmc in exynos


I'll let Kukjin decide what he wants to do about the regression in
v3.17 (how to deal with conflicts, backporting, etc).


-Doug
--
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: Unable to boot mainline on snow chromebook since 3.15

[Doug Anderson]

Grant,

On Wed, Sep 10, 2014 at 9:29 AM, Grant Likely grant.lik...@secretlab.ca wrote:
 On Wed, Sep 10, 2014 at 4:39 PM, Mark Brown broo...@kernel.org wrote:
 On Wed, Sep 10, 2014 at 03:56:16PM +0100, Grant Likely wrote:
 On Wed, Sep 10, 2014 at 3:31 PM, Mark Brown broo...@kernel.org wrote:

  As far as I can tell the problem here is coming from the decision to
  have simplefb use resources without knowing about them - can we agree
  that this is a bad idea?

 No, I don't think we can... there is a certain amount of firmware got
 things working for us, and we're going to use it for a while that is
 absolutely reasonable. simplefb is a good example, but there are
 certainly others.

 That bit is fine - I definitely think it's reasonable to have things
 like this where the device is initialized prior to the kernel starting
 and we use some simplified subset.  What I think is a big problem here
 is that we're not being told what parts of the system state are relevant
 to this initialization (worse, we're being told things that are actively
 wrong for some of the resources).  This seems inherently fragile.

 I /do/ think it would be better for the simplefb data to get embedded
 or linked into the node of the graphics controller so that it can be
 torn down appropriately, and we need a rule for how long boot-state
 can be considered valid so that a proper driver can either reserve the
 resources for a given SoC, or do a full handoff from the simplefb.
 Even without that though, we need to be able to handle the case of an
 anonymous simplefb node with no regulator information. If that means
 the default simplefb behaviour is to inhibit runtime pm on all
 resources until a real driver show up, then that might just be what we
 need to do.

 I think saying that it's a good idea to have an simplefb node without
 resource management is exactly the problem here - if we start from the
 assumption that this is a good idea we do get dragged down this path but
 it seems like we took a wrong turn going that way in the first place.

 It's not just regulators - we've got exactly the same problem with
 clocks on this system for example, they're also getting disabled because
 they seem unused and users have to pass in a kernel command line bodge
 to avoid that.  We'd also have an issue if something decided to change
 the rates of some of the clocks, and power domains have the same problem
 (Ulf's patches to genericise their code has the same behaviour with
 regard to powering off unused domains, some of the existing
 implementations do that already).

 Two things should probably be changed from the current setup. 1)
 simplefb shouldn't be a platform driver. It is a boot thing that
 handles initial state from the graphics chip. By implementing it as a
 platform driver, it prevents the real driver from binding to the real
 device if the simplefb data embedded into it. 2) make sure that an SoC
 driver can protect the needed resources before they are automatically
 disabled. Either by putting them in an earlier initcall, or handling
 it in the subsystem code. I don't know enough about the regulator and
 clock runtime PM to know what the best way to do this is.

 Right, I agree with what you're saying here but what I'm saying is that
 the way to ensure that the resources are protected is for the simplefb
 node to tell the kernel what resources are being used, otherwise it
 seems like we're just guessing and will fall over ourselves sooner or
 later.

 We can't use initcall hacks as these only work in cases where we will at
 some point hand over to a real driver and there seems to be a clear use
 case for using simplefb prior to that driver being written; even where
 we will hand over to a real driver we can't put a definite timescale on
 that happening since in the distro case it might be being loaded from
 disk at some point after userspace is running.

 What we can do is have an inhibit flag for
 simplefb/simpleuart/simplewhatever that holds off PM. When a real
 driver, or a stub that understands parsing the resource dependencies,
 takes ownership of the device (or userspace tells the kernel to stop
 caring) it can clear the inhibit.

This doesn't seem crazy, though it means that if you're planning on
using nothing but simplefb then you're never going to be able to get
any power savings anywhere.

Right now I know that clock disabling is supposed to be inhibited
during the early boot process.  I think regulators too?


 I don't want to build knowledge of resource dependencies into the
 simple case. We'll simply frequently get it wrong. For example: A
 future kernel will have better PM and will turn off more devices which
 isn't accounted for in an older DT.

In IRC I made a suggestion that perhaps the simplefb ought to be put
in the main in-kernel dts file but with no address information and
set to disabled.  Then the firmware can do something very simple:
set to enabled and fill in the address.

Right now the firmware is taking 

Re: Unable to boot mainline on snow chromebook since 3.15

[Doug Anderson]

Mark,

On Wed, Sep 10, 2014 at 12:45 PM, Mark Brown broo...@kernel.org wrote:
 On Wed, Sep 10, 2014 at 09:45:21AM -0700, Doug Anderson wrote:

 Right now I know that clock disabling is supposed to be inhibited
 during the early boot process.  I think regulators too?

 No, for regulators we'll quite happily disable anything a consumer asks
 us to at any point but we'll only do a sweep for regulators that were
 enabled on startup then not subsequently referenced and turn them off in
 late_initcall.

Ah, that sounds exactly like the clock framework then.  I think I just
didn't explain the clock framework properly.

-Doug
--
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 v3 6/7] ARM: dts: Set i2c7 clock at 400kHz for Peach boards

[Doug Anderson]

Javier,

On Wed, Sep 10, 2014 at 3:19 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 The downstream ChromeOS 3.8 kernel sets the clock frequency
 for the I2C bus 7 at 400kHz. Do the same change in mainline.

 Suggested-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 +
  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 1 +
  2 files changed, 2 insertions(+)

Reviewed-by: Doug Anderson diand...@chromium.org
--
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 v3 7/7] ARM: exynos_defconfig: Enable MAX77802

[Doug Anderson]

Javier,

On Wed, Sep 10, 2014 at 3:19 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 From: Vivek Gautam gautam.vi...@samsung.com

 Enabled MAX77802 pmic for exynos systems.
 One config USB_ANNOUNCE_NEW_DEVICES to display device
 information on connect.
 Another config for I2C_CHARDEV to see i2c device nodes.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/configs/exynos_defconfig | 3 +++
  1 file changed, 3 insertions(+)

I've no complaints about any of that.

Reviewed-by: Doug Anderson diand...@chromium.org
--
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 1/5] ARM: dts: Add Peach Pit and Pi dts entry for max77802 PMIC

[Doug Anderson]

Javier,

On Wed, Aug 20, 2014 at 4:19 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 Exynos5420 based Peach Pit and Exynos5800 based Peach Pi boards
 uses a Maxim 77802 power management IC to drive regulators and
 its Real Time Clock. This patch adds support for this chip.

 These are the device nodes and pinctrl configuration that
 are present on the Peach pit DeviceTree source file in the
 the Chrome OS kernel 3.8 tree.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Tested-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
 ---
  arch/arm/boot/dts/exynos5420-peach-pit.dts | 372 
 +
  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 372 
 +
  2 files changed, 744 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
 b/arch/arm/boot/dts/exynos5420-peach-pit.dts
 index ab06148..78cea4c 100644
 --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
 +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
 @@ -11,6 +11,7 @@
  /dts-v1/;
  #include dt-bindings/input/input.h
  #include dt-bindings/gpio/gpio.h
 +#include dt-bindings/interrupt-controller/irq.h
  #include exynos5420.dtsi

  / {
 @@ -144,6 +145,339 @@
 ddc = i2c_2;
  };

 +hsi2c_4 {
 +   status = okay;
 +   clock-frequency = 40;
 +
 +   max77802-pmic@9 {
 +   compatible = maxim,max77802;
 +   interrupt-parent = gpx3;
 +   interrupts = 1 IRQ_TYPE_NONE;
 +   pinctrl-names = default;
 +   pinctrl-0 = max77802_irq, pmic_selb,
 +   pmic_dvs_1, pmic_dvs_2, pmic_dvs_3;
 +   wakeup-source;
 +   reg = 0x9;
 +   #clock-cells = 1;

...you've actually got the 32k clock specified in a reasonable way now
(unlike our tree).

We don't have opmode or the DVFS stuff upstream yet, so makes sense
that's not here.


 +   inb1-supply = tps65090_dcdc2;
 +   inb2-supply = tps65090_dcdc1;
 +   inb3-supply = tps65090_dcdc2;
 +   inb4-supply = tps65090_dcdc2;
 +   inb5-supply = tps65090_dcdc1;
 +   inb6-supply = tps65090_dcdc2;
 +   inb7-supply = tps65090_dcdc1;
 +   inb8-supply = tps65090_dcdc1;
 +   inb9-supply = tps65090_dcdc1;
 +   inb10-supply = tps65090_dcdc1;
 +
 +   inl1-supply = buck5_reg;
 +   inl2-supply = buck7_reg;
 +   inl3-supply = buck9_reg;
 +   inl4-supply = buck9_reg;
 +   inl5-supply = buck9_reg;
 +   inl6-supply = tps65090_dcdc2;
 +   inl7-supply = buck9_reg;
 +   inl9-supply = tps65090_dcdc2;
 +   inl10-supply = buck7_reg;

I double-checked your input supplies against schematics (since we
don't have them right in our tree).  They look right.

 +
 +   regulators {
 +   buck1_reg: BUCK1 {
 +   regulator-name = vdd_mif;
 +   regulator-min-microvolt = 80;
 +   regulator-max-microvolt = 130;
 +   regulator-always-on;
 +   regulator-boot-on;
 +   regulator-ramp-delay = 12500;
 +   };
 +
 +   buck2_reg: BUCK2 {
 +   regulator-name = vdd_arm;
 +   regulator-min-microvolt = 80;
 +   regulator-max-microvolt = 150;
 +   regulator-always-on;
 +   regulator-boot-on;
 +   regulator-ramp-delay = 12500;
 +   };
 +
 +   buck3_reg: BUCK3 {
 +   regulator-name = vdd_int;
 +   regulator-min-microvolt = 80;
 +   regulator-max-microvolt = 140;
 +   regulator-always-on;
 +   regulator-boot-on;
 +   regulator-ramp-delay = 12500;
 +   };
 +
 +   buck4_reg: BUCK4 {
 +   regulator-name = vdd_g3d;
 +   regulator-min-microvolt = 70;
 +   regulator-max-microvolt = 140;
 +   regulator-always-on;
 +   regulator-boot-on;
 +   regulator-ramp-delay = 12500;
 +   };
 +
 +   buck5_reg: BUCK5 {
 +   regulator-name = vdd_1v2;
 +   regulator-min-microvolt = 120;
 +   regulator-max-microvolt = 120;
 +   regulator-always-on;
 

Re: [PATCH 2/6] ARM: dts: add hdmi regulators for exynos5800 based peach-pi board

[Doug Anderson]

Javier / Rahul,

On Tue, Aug 19, 2014 at 8:08 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 From: Rahul Sharma rahul.sha...@samsung.com

 Adding regulators for HDMI for Peach-pi board.

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---

 v2: 1) Add blank line before hdmi regulators.

  arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 +
  1 file changed, 5 insertions(+)

Reviewed-by: Doug Anderson diand...@chromium.org
--
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/6] ARM: dts: add hdmi regulators for exynos5800 based peach-pi board

[Doug Anderson]

Hi,

On Tue, Sep 9, 2014 at 9:44 PM, Doug Anderson diand...@chromium.org wrote:
 Javier / Rahul,

 On Tue, Aug 19, 2014 at 8:08 AM, Javier Martinez Canillas
 javier.marti...@collabora.co.uk wrote:
 From: Rahul Sharma rahul.sha...@samsung.com

 Adding regulators for HDMI for Peach-pi board.

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---

 v2: 1) Add blank line before hdmi regulators.

  arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 +
  1 file changed, 5 insertions(+)

 Reviewed-by: Doug Anderson diand...@chromium.org

Meant to add this to the v2.  Sorry for the spam...
--
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 2/5] ARM: dts: add hdmi regulators for exynos5800 based peach-pi board

[Doug Anderson]

Javier / Rahul,

On Wed, Aug 20, 2014 at 4:19 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 From: Rahul Sharma rahul.sha...@samsung.com

 Adding regulators for HDMI for Peach-pi board.

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 +
  1 file changed, 5 insertions(+)

Reviewed-by: Doug Anderson diand...@chromium.org
--
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 3/5] ARM: dts: add hdmi regulators for exynos5420 based peach-pit board

[Doug Anderson]

Javier / Rahul.

On Wed, Aug 20, 2014 at 4:19 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 From: Rahul Sharma rahul.sha...@samsung.com

 Adding regulators for hdmi for peach-pit board.

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/exynos5420-peach-pit.dts | 5 +
  1 file changed, 5 insertions(+)

Reviewed-by: Doug Anderson diand...@chromium.org
--
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 4/5] ARM: dts: Add thermistor dts fragment used by exynos based Peach boards

[Doug Anderson]

Javier / Naveen,

On Wed, Aug 20, 2014 at 4:19 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 From: Naveen Krishna Chatradhi ch.nav...@samsung.com

 This patch creates a thermistor fragment carrying the NTC Thermistor
 nodes as children of the IIO based ADC.

 This fragment is included in exynos5420-peach-pit.dts and
 exynos5800-peach-pi.dts.

 Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/cros-adc-thermistors.dtsi | 44 
 +
  arch/arm/boot/dts/exynos5420-peach-pit.dts  |  6 
  arch/arm/boot/dts/exynos5800-peach-pi.dts   |  6 
  3 files changed, 56 insertions(+)

Reviewed-by: Doug Anderson diand...@chromium.org
--
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 5/5] ARM: dts: Add Peach Pit and Pi dts entry for ISL29018 sensor

[Doug Anderson]

Javier,

On Wed, Aug 20, 2014 at 4:19 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 The Exynos5420 based Peach Pit and the Exynos5800 based Peach Pi
 machines have an i2c ISL29018 light sensor. This patch adds the
 device nodes needed to support this device.

 These DTS snippets were taken from the downstream Chrome OS 3.8
 kernel Device Tree for Peach Pit and Pi boards.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/exynos5420-peach-pit.dts | 6 ++
  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 6 ++
  2 files changed, 12 insertions(+)

I would note that the downstream dts file has this i2c bus at 400kHz.
...but that's not a problem with your patch.  Perhaps you could submit
that as a separate patch?

Reviewed-by: Doug Anderson diand...@chromium.org
--
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 0/5] Add max77802 support for Peach boards

[Doug Anderson]

Hi,

On Mon, Sep 8, 2014 at 8:47 PM,  kg...@kernel.org wrote:
 Javier Martinez Canillas wrote:

 Hello Kukjin,

 Hi,

 On Wed, Aug 20, 2014 at 1:19 PM, Javier Martinez Canillas
 javier.marti...@collabora.co.uk wrote:
 
  This is a second version of the series that adds max77802 support for
  the Peach Pit and Pi boards. The series also have all the pending
  patches that were posted but depended on this support. I've picked
  all the patches I found and rebased them to be sure that they apply
  cleanly on top of linux-next. Also I've taken some DT snippets from
  the downstream Chrome OS 3.8 kernel DTS for devices that use one of
  these regulators as their input supply.
 

 Any comments on this series?

 Looks good to me but I just wanted to get ack from chrome guy, Doug? But since
 Naveen tested, it should be fine I think. I'll take the series.

I haven't had crazy amounts of time to review pit/pi patches recently,
but luckily Javier has been picking up my slack.  I think he's more of
a maintainer for these file than I am at this point.

...but I did do a quick skim / compare to our tree and found one small
bug (see patch #1) and added my Reviewed-by tags.

-Doug


-Doug
--
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: Unable to boot mainline on snow chromebook since 3.15

[Doug Anderson]

Javier,

On Sun, Sep 7, 2014 at 11:09 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 Hello Doug,

 On 09/08/2014 06:36 AM, Doug Anderson wrote:

 One (ugly?) solution would be to add a feature to your bootloader to
 modify the device tree to mark regulators as always-on.  Since the
 booloader gets to touch the device tree and the bootloader is involved
 in communicating into about SimpleFB, it kinda makes sense.


 I can't say I like to mark the regulators as always-on on the DT and that's
 why I copied the patch in the response instead of posting it as a proper patch
 but I think relying in the bootloaders to modify the DT is not better.

 IMHO U-boot should only modify the strictly necessary like the /chosen branch
 even though lately I've seen some attempts in the OMAP community to (ab)use
 U-Boot's fdt command to mangle the DT before passing to the kernel in order to
 support different Beagle Bone Black capes.

So simple-framebuffer is added to the device tree here:

https://chromium-review.googlesource.com/#/c/49358/2/board/samsung/smdk5250/smdk5250.c

That's one of the two patches to build your own U-Boot for enabling
simplefb.  You'll notice that's not a super official thing.  It's a
DO NOT SUBMIT patch sitting in a gerrit code review server, so I
wouldn't exactly call it a stable ABI that we can't break.  It's not
something shipping in real products and it's not even landed in a git
tree (I suppose maybe someone somewhere landed it, but...).

To me, that means that if someone is using that patch and it works for
them, then that's great!  If it stops working (possibly because it was
making assumptions about the state of the kernel) then it should be
fixed up.

In this case, that patch really should be adding references to
regulators (and possibly clocks) that are needed.  Given that this
patch is already reaching into the device tree to add the
simple-framebuffer node, it doesn't seem unreasonable to say that it
should be grabbing the proper references (or mark regulators as
always-on).


...as always, though, remember that my opinion doesn't count for much.
I also sympathize with the problems people are running into.  :(
--
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: Unable to boot mainline on snow chromebook since 3.15

[Doug Anderson]

Grant,

On Mon, Sep 8, 2014 at 5:20 AM, Grant Likely grant.lik...@secretlab.ca wrote:
 On Mon, Sep 8, 2014 at 12:21 PM, Will Deacon will.dea...@arm.com wrote:
 On Sun, Sep 07, 2014 at 05:19:03PM +0100, Tomasz Figa wrote:
 At least for next 3.17-rc I'd suggest fixing this up in respective clock
 driver and dropping the hack only after Exynos DRM patches are merged
 and confirmed working.

 Whilst I'm sympathetic to people working to enable DRM, I think this is
 the right solution to the problem. The transition from simplefb to DRM
 shouldn't break display for a bunch of kernel revisions whilst the code is
 in flux.

 I would go further. The kernel behaviour has changed, and we have to
 deal with platforms that assume the old behaviour. That means either
 defaulting to leaving enabled regulators/clocks alone unless there is
 a flag in the DT saying they can be power managed, or black listing
 platforms that are known to depend on the regulator being on.

 Updating the device tree must not be required to get the kernel to
 boot, but it is valid to require a DT upgrade to get better
 performance (battery life) out of the platform.

In this case people using SImple FB are not really using an officially
sanctioned device tree.  The simple-fb fragment is created on the fly
via a DO NOT SUBMIT patch sitting on a code review server.  It's not
something that's shipped with real firmware nor is it something
present in the kernel.  See
https://chromium-review.googlesource.com/#/c/49358/2/board/samsung/smdk5250/smdk5250.c
as I mentioned above.

Is this really a device tree that we need to guarantee backward
compatibility with?


-Doug
--
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: Unable to boot mainline on snow chromebook since 3.15

[Doug Anderson]

Will,

On Mon, Sep 8, 2014 at 9:07 AM, Will Deacon will.dea...@arm.com wrote:
 On Mon, Sep 08, 2014 at 04:55:31PM +0100, Doug Anderson wrote:
 So simple-framebuffer is added to the device tree here:

 https://chromium-review.googlesource.com/#/c/49358/2/board/samsung/smdk5250/smdk5250.c

 That's one of the two patches to build your own U-Boot for enabling
 simplefb.  You'll notice that's not a super official thing.  It's a
 DO NOT SUBMIT patch sitting in a gerrit code review server, so I
 wouldn't exactly call it a stable ABI that we can't break.  It's not
 something shipping in real products and it's not even landed in a git
 tree (I suppose maybe someone somewhere landed it, but...).

 I just took the uboot image linked to from the chromium.org page here:

   
 http://www.chromium.org/chromium-os/u-boot-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook#TOC-Getting-nv-U-Boot

Ah, OK.  It's still using the DO NOT SUBMIT patchs, but I guess
given that there is a binary built up there by a fairly official
source...  Hrmm.  I think Olof is the one that built that.  Perhaps
he'd be willing to muck with that and see if he can grab the
regulators?

-Doug
--
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: Unable to boot mainline on snow chromebook since 3.15

[Doug Anderson]

Hi,

On Sun, Sep 7, 2014 at 8:52 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
 So I believe we've got a process issue here. If you don't have normal
 support for display hardware, but you want to keep the display
 operational thanks to bootloader already initializing it, you should not
 add anything to the kernel which breaks it, until full support comes in.

 This means that respective regulators should be either always-on or not
 listed at all (I'd favor the former) and respective clocks either
 somehow enabled at boot-up or completely ignored, including all their
 parents capable of being gated.

It seems slightly broken to hack the device tree in this way.  I'll be
the first to admit that I often list regulators as always-on during
bringup when not everything is done, and I guess it's not that
different.  ...but given everything going on upstream (and people
working on Suspend/Resume, DRM, etc) it seems like it might be a bit
of a pain.  ...but if that's what everyone agrees on, I won't disagree
too strongly.

One (ugly?) solution would be to add a feature to your bootloader to
modify the device tree to mark regulators as always-on.  Since the
booloader gets to touch the device tree and the bootloader is involved
in communicating into about SimpleFB, it kinda makes sense.
--
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: Unable to boot mainline on snow chromebook since 3.15

[Doug Anderson]

Hi,

On Sun, Sep 7, 2014 at 8:52 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
 Now with regulators this is pretty straightforward, but with clocks I
 believe it's an open issue. AFAIR we've discussed this on MLs some time
 ago (at least I remember Doug commenting on that topic) and kind of
 concluded that SoC clock drivers could include lists of clocks to be
 enabled at boot-up (as a HACK to enable things like simplefb until
 proper support for respective features are added).

I think my old problem was with earlyprintk and a core clock getting
disabled.  See (44ff025 clk: exynos5420: Remove aclk66_peric from the
clock tree description).  I think I've seen others solve the same
problem with the concept of critical clocks.

I agree that regulator and clock frameworks allow very different hacks.  ;)

-Doug
--
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: Unable to boot mainline on snow chromebook since 3.15

[Doug Anderson]

Will,

On Fri, Sep 5, 2014 at 5:22 AM, Will Deacon will.dea...@arm.com wrote:
 [Looks like it's not just Rutland that can't spell the address of the
  mailing list today. Fixed here, so please use this post in any replies].

 On Fri, Sep 05, 2014 at 12:57:04PM +0100, Will Deacon wrote:
 Hi all,

 I'm one of the few, foolish people to try running mainline on my 5250-based
 Samsung Chromebook (snow). I can live without wireless, usb3 and video
 acceleration, so actually it makes a reasonable development platform for
 doing A15-based (micro)-architectural work.

 However, since 3.15 I've not been able to boot *any* mainline kernels on
 this board. I did mean to report this earlier, but I have other machines
 that can run mainline so this has fallen by the wayside.

 The problems started with 3.16, where simple-fb would fail to initialise
 and I lost my display. Note that I don't have a serial console on this
 machine (I looked at the PCB and there's no way I can solder one of those
 myself :) I bisected the issue at the time, and I could get my display back
 by removing some of the new regulator and hdmi properties from the DT. At
 that point, I could boot, but DMA didn't initialise for the MMC controller
 so I couldn't mount my root filesystem.

 With 3.17-rc3, it seems a lot worse -- I don't get any output after nv-uboot
 (i.e. the nv-uboot screen just remains on the display, with the last line
 reading Stashed 20 records).

 I'd usually try to debug this a bit further, but without a console it's
 really painful to get anywhere. I've been working with 3.15, but now I'm
 having to backport patches when I want to test them, which is more effort
 than I can be bothered with.

 Is anybody else running mainline on this device and are these known/fixed
 problems?

I've added Javier, who says he'll try to take a look at the problem on
Monday.  He's got a snow and I think he's got a serial console hooked
up to it (but I don't think he's tried the simplefb workflow).


He also added the following thoughts:

 Have you seen the very long [PATCH 4/4] simplefb: add clock handling
 code thread [0]?. I wonder if the problem is that the display clocks were
 not known to the kernel before 3.15 but now are getting disabled and thus
 the simplefb driver not working?

 So probably is worth to try passing clk_ignore_unused as a parameter to
 the kernel command line.

 [0]: https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg06623.html
--
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 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc

[Doug Anderson]

Ulf,

On Thu, Aug 28, 2014 at 12:25 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 27 August 2014 17:52, Doug Anderson diand...@google.com wrote:
 Ulf,

 On Wed, Aug 27, 2014 at 4:17 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 Now, we've got MMC_CAP_NEEDS_POLL, so dw_mmc will periodically be
 called to check the card detect line, but with vmmc and vqmmc off.  It
 will be unable to return a sensible value without actually turning on
 vmmc and vqmmc.

 Currently MMC_CAP_NEEDS_POLL mean the mmc rescan work will reschedule
 itself with HZ interval. This to check for card insert/removal.

 Now, mmc_rescan() will, if present, invoke host's -get_cd() callback
 to check whether it's worth to continue initialization sequence or if
 it should re-schedule itself again.

 If your host driver can distinguish whether a card is inserted, which
 in this case are when vccq is turned off, your -get_cd() callback need
 to return 1. That will allow mmc_rescan() to continue it's
 initialization sequence and do mmc_power_up().

 As per my other email, we can't tell whether a card is inserted when
 vqmmc is off.

 I understand.

 The solution I proposed above, is:

 1) Enable MMC_CAP_NEEDS_POLL.
 2) Make -get_cd() return 1, when you can't distinguish if the card is 
 inserted.

 That will solve this issue and without messing up the mmc core.

Ah, I see!  So every 1 second, we'll do the following:

1. Call get_cd(), which returns 1.

2. MMC core will power everything up (turn on all regulators) for MMC.

3. We'll start to initialize a card.

4. We'll notice that, oops, there's no card there.

5. MMC core will shut things down again.


That seems awfully expensive to do every second when the card detect
line actually does work (as long as you keep power lines).  Is the
patch to separate out the concepts of power off because no card is
inserted and power off because we're power cycling the card really
bad enough to warrant forcing us to use the above?

I'm not an EE, but cycling regulators on and off every second doesn't
seem super ideal, but maybe they're designed for it?


Personally, I'd be tempted to just leave the power on all the time and
if a card somehow needs to be power cycled (because UHS negotiation
failed?) then that card just isn't supported.  This could be done in
the dts by saying that the regulator is always on and no need to
pollute any source files.


-Doug
--
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 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc

[Doug Anderson]

Jaehoon,

On Thu, Aug 28, 2014 at 1:43 AM, Jaehoon Chung jh80.ch...@samsung.com wrote:
 On 08/28/2014 12:49 AM, Doug Anderson wrote:
 Jaehoon,

 On Tue, Aug 26, 2014 at 9:47 PM, Jaehoon Chung jh80.ch...@samsung.com 
 wrote:
 Doug,

 On 08/27/2014 01:14 PM, Doug Anderson wrote:
 Jaehoon,

 On Tue, Aug 26, 2014 at 8:48 PM, Jaehoon Chung jh80.ch...@samsung.com 
 wrote:
 Hi, Doug,

 On 08/26/2014 12:25 AM, Doug Anderson wrote:
 Jaehoon,

 On Mon, Aug 25, 2014 at 1:50 AM, Jaehoon Chung jh80.ch...@samsung.com 
 wrote:
 On 08/25/2014 05:13 PM, Ulf Hansson wrote:
 On 22 August 2014 20:27, Sonny Rao sonny...@chromium.org wrote:
 On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson ulf.hans...@linaro.org 
 wrote:
 On 22 August 2014 15:47, Yuvaraj Kumar C D yuvaraj...@gmail.com 
 wrote:
 Exynos 5250 and 5420 based boards uses built-in CD# line for card
 detection.But unfortunately CD# line is on the same voltage rails
 as of I/O voltage rails. When we cut off vqmmc,the consequent card
 detection will break in these boards.

 I didn't know that use CD# line for card detect.
 And if CD# voltage rails and I/O voltage rail are same voltage, it 
 doesn't make sense.
 Which card is used with same voltages? (eMMC? SD? SDIO?)

 Well, I have checked Exynos5250 and 5420, but it looks like not same 
 rails.

 I'm not sure I totally understood what you said.  In my manual I have
 a table titled Table 2-1 Exynos 5420 Pin List.  Look in this table
 for XMMC2CDN and XMMC2DATA_0.  Look to the right of the table and
 you'll see the power domain.  For both it shows VDDQ_MMC2.  If that
 doesn't mean that the two are in the same voltage domain then I don't
 know what does.  Can you point to any examples where they have
 different voltage domains?
 I think you're mis-understanding for it.
 Right, It's described at exynos5420, but it's not connected.

 It's not connected.  What do you mean?  If I were to guess I'd say
 that on some particular board you're looking at they don't happen to
 use the CD pin for card detect.  If this is what you mean, it
 doesn't help me.  exynos5420-peach-pit does use the CD pin for card
 detect.  You can look at the DTS file and confirm it.

 I didn't know how exynos5420-peach-pit's circuit is configured.
 But i guess that almost all exynos5 boards are configured with the similar 
 circuit.

 At Almost all Exynos5 board, CD-pin is used, but not included in Same power 
 domain.
 (CD-pin is external card-detect pin. - like XEINT_# pin)
 You mentioned CD# and DATA# lines is used the same power domain, right?
 In Circuit (not exynos5420-peach-pit), DATA# line and CMD/CLK(vqmmc) is 
 same power supply, and vdd is used other power supply.
 Not use the CD# pin, used the XEINT_# pin.
 So i think we don't need to consider the CD#.
 If exynos5420-peach-pit board is used the CD#-pin, then our discussion can 
 be changed.

 Maybe on your board you have CD connected to a gpx line.  ...but not
 mine.  The guys who designed our hardware followed the SMDK5420
 reference schematics which connect the SD card slot card detect to
 gpc2_2, which is the card detect pin.

 See arch/arm/boot/dts/exynos5420-smdk5420.dts, specifically noting
 the lack of a GPIO card detect and the inclusion of sd2_cd

 mmc@1222 {
   status = okay;
   card-detect-delay = 200;
   samsung,dw-mshc-ciu-div = 3;
   samsung,dw-mshc-sdr-timing = 2 3;
   samsung,dw-mshc-ddr-timing = 1 2;
   pinctrl-names = default;
   pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
   bus-width = 4;
   cap-sd-highspeed;
 };

 See arch/arm/boot/dts/exynos5420-peach-pit.dts too:

 mmc_2 {
   status = okay;
   num-slots = 1;
   cap-sd-highspeed;
   card-detect-delay = 200;
   clock-frequency = 4;
   samsung,dw-mshc-ciu-div = 3;
   samsung,dw-mshc-sdr-timing = 2 3;
   samsung,dw-mshc-ddr-timing = 1 2;
   pinctrl-names = default;
   pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
   bus-width = 4;
 };


 Here, see this ASCII art that shows how some lines are hooked up on
 peach-pit.  You might need to paste this into something with a
 fixed-width font.

  +
  |Exynos 5420
  |
  |
 P2.8V_LOUT4 -|- VDDQ_MMC2 (AK7)
 ||
 ||
   +-+- 10K res -+|- XMMC2CDN (AK6)
   | ||
   | ||
   | ||
   |   Ext CD |
   |  |
   +-- 10K res-+--+---|- XMMC2CMD (AK8)
  |
  |
Ext CMD

 You can see from the above that the external card detect signal (that
 goes to the connector) named Ext CD is pulled up to the same voltage
 as the external CMD signal (that also goes to the connector).  This is
 vqmmc.  If we turn off vqmmc then the 10K resistor will (I think) act
 as a pull down, or in the best case it will be floating.

 Said another way: we can't read card detect when vqmmc is off.

 If that's the case, it makes sense. But i wonder why

Re: [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc

[Doug Anderson]

Hi,

On Thu, Aug 28, 2014 at 10:50 AM, Sonny Rao sonny...@chromium.org wrote:
 On Thu, Aug 28, 2014 at 8:50 AM, Doug Anderson diand...@google.com wrote:
 Ulf,

 On Thu, Aug 28, 2014 at 12:25 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 27 August 2014 17:52, Doug Anderson diand...@google.com wrote:
 Ulf,

 On Wed, Aug 27, 2014 at 4:17 AM, Ulf Hansson ulf.hans...@linaro.org 
 wrote:
 Now, we've got MMC_CAP_NEEDS_POLL, so dw_mmc will periodically be
 called to check the card detect line, but with vmmc and vqmmc off.  It
 will be unable to return a sensible value without actually turning on
 vmmc and vqmmc.

 Currently MMC_CAP_NEEDS_POLL mean the mmc rescan work will reschedule
 itself with HZ interval. This to check for card insert/removal.

 Now, mmc_rescan() will, if present, invoke host's -get_cd() callback
 to check whether it's worth to continue initialization sequence or if
 it should re-schedule itself again.

 If your host driver can distinguish whether a card is inserted, which
 in this case are when vccq is turned off, your -get_cd() callback need
 to return 1. That will allow mmc_rescan() to continue it's
 initialization sequence and do mmc_power_up().

 As per my other email, we can't tell whether a card is inserted when
 vqmmc is off.

 I understand.

 The solution I proposed above, is:

 1) Enable MMC_CAP_NEEDS_POLL.
 2) Make -get_cd() return 1, when you can't distinguish if the card is 
 inserted.

 That will solve this issue and without messing up the mmc core.

 Ah, I see!  So every 1 second, we'll do the following:

 1. Call get_cd(), which returns 1.

 2. MMC core will power everything up (turn on all regulators) for MMC.

 3. We'll start to initialize a card.

 4. We'll notice that, oops, there's no card there.

 5. MMC core will shut things down again.


 That seems awfully expensive to do every second when the card detect
 line actually does work (as long as you keep power lines).  Is the
 patch to separate out the concepts of power off because no card is
 inserted and power off because we're power cycling the card really
 bad enough to warrant forcing us to use the above?

 I'm not an EE, but cycling regulators on and off every second doesn't
 seem super ideal, but maybe they're designed for it?


 Personally, I'd be tempted to just leave the power on all the time and
 if a card somehow needs to be power cycled (because UHS negotiation
 failed?) then that card just isn't supported.  This could be done in
 the dts by saying that the regulator is always on and no need to
 pollute any source files.

 Yeah, power cycling the regulators constantly doesn't seem like a
 great idea, we can ask the EEs what they think.

 This scheme of leaving them on all the time would prevent us from
 being able to actually power cycle the card, which I think is required
 by the spec in case UHS negotiation fails.

OK, fair enough.  I guess polling is less bad than nor supporting card
power cycling.  ...it still feels like adding this quirk to the core
isn't super ugly, but if everyone is against it...


-Doug
--
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 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc

[Doug Anderson]

Jaehoon,

On Tue, Aug 26, 2014 at 9:47 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
 Doug,

 On 08/27/2014 01:14 PM, Doug Anderson wrote:
 Jaehoon,

 On Tue, Aug 26, 2014 at 8:48 PM, Jaehoon Chung jh80.ch...@samsung.com 
 wrote:
 Hi, Doug,

 On 08/26/2014 12:25 AM, Doug Anderson wrote:
 Jaehoon,

 On Mon, Aug 25, 2014 at 1:50 AM, Jaehoon Chung jh80.ch...@samsung.com 
 wrote:
 On 08/25/2014 05:13 PM, Ulf Hansson wrote:
 On 22 August 2014 20:27, Sonny Rao sonny...@chromium.org wrote:
 On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson ulf.hans...@linaro.org 
 wrote:
 On 22 August 2014 15:47, Yuvaraj Kumar C D yuvaraj...@gmail.com 
 wrote:
 Exynos 5250 and 5420 based boards uses built-in CD# line for card
 detection.But unfortunately CD# line is on the same voltage rails
 as of I/O voltage rails. When we cut off vqmmc,the consequent card
 detection will break in these boards.

 I didn't know that use CD# line for card detect.
 And if CD# voltage rails and I/O voltage rail are same voltage, it 
 doesn't make sense.
 Which card is used with same voltages? (eMMC? SD? SDIO?)

 Well, I have checked Exynos5250 and 5420, but it looks like not same 
 rails.

 I'm not sure I totally understood what you said.  In my manual I have
 a table titled Table 2-1 Exynos 5420 Pin List.  Look in this table
 for XMMC2CDN and XMMC2DATA_0.  Look to the right of the table and
 you'll see the power domain.  For both it shows VDDQ_MMC2.  If that
 doesn't mean that the two are in the same voltage domain then I don't
 know what does.  Can you point to any examples where they have
 different voltage domains?
 I think you're mis-understanding for it.
 Right, It's described at exynos5420, but it's not connected.

 It's not connected.  What do you mean?  If I were to guess I'd say
 that on some particular board you're looking at they don't happen to
 use the CD pin for card detect.  If this is what you mean, it
 doesn't help me.  exynos5420-peach-pit does use the CD pin for card
 detect.  You can look at the DTS file and confirm it.

 I didn't know how exynos5420-peach-pit's circuit is configured.
 But i guess that almost all exynos5 boards are configured with the similar 
 circuit.

 At Almost all Exynos5 board, CD-pin is used, but not included in Same power 
 domain.
 (CD-pin is external card-detect pin. - like XEINT_# pin)
 You mentioned CD# and DATA# lines is used the same power domain, right?
 In Circuit (not exynos5420-peach-pit), DATA# line and CMD/CLK(vqmmc) is same 
 power supply, and vdd is used other power supply.
 Not use the CD# pin, used the XEINT_# pin.
 So i think we don't need to consider the CD#.
 If exynos5420-peach-pit board is used the CD#-pin, then our discussion can be 
 changed.

Maybe on your board you have CD connected to a gpx line.  ...but not
mine.  The guys who designed our hardware followed the SMDK5420
reference schematics which connect the SD card slot card detect to
gpc2_2, which is the card detect pin.

See arch/arm/boot/dts/exynos5420-smdk5420.dts, specifically noting
the lack of a GPIO card detect and the inclusion of sd2_cd

mmc@1222 {
  status = okay;
  card-detect-delay = 200;
  samsung,dw-mshc-ciu-div = 3;
  samsung,dw-mshc-sdr-timing = 2 3;
  samsung,dw-mshc-ddr-timing = 1 2;
  pinctrl-names = default;
  pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
  bus-width = 4;
  cap-sd-highspeed;
};

See arch/arm/boot/dts/exynos5420-peach-pit.dts too:

mmc_2 {
  status = okay;
  num-slots = 1;
  cap-sd-highspeed;
  card-detect-delay = 200;
  clock-frequency = 4;
  samsung,dw-mshc-ciu-div = 3;
  samsung,dw-mshc-sdr-timing = 2 3;
  samsung,dw-mshc-ddr-timing = 1 2;
  pinctrl-names = default;
  pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
  bus-width = 4;
};


Here, see this ASCII art that shows how some lines are hooked up on
peach-pit.  You might need to paste this into something with a
fixed-width font.

 +
 |Exynos 5420
 |
 |
P2.8V_LOUT4 -|- VDDQ_MMC2 (AK7)
||
||
  +-+- 10K res -+|- XMMC2CDN (AK6)
  | ||
  | ||
  | ||
  |   Ext CD |
  |  |
  +-- 10K res-+--+---|- XMMC2CMD (AK8)
 |
 |
   Ext CMD

You can see from the above that the external card detect signal (that
goes to the connector) named Ext CD is pulled up to the same voltage
as the external CMD signal (that also goes to the connector).  This is
vqmmc.  If we turn off vqmmc then the 10K resistor will (I think) act
as a pull down, or in the best case it will be floating.

Said another way: we can't read card detect when vqmmc is off.

 Your commit message looks like all exynos5250/5420 board are used CD# line.

The commit message should be clearer, agreed.  I think I asked Yuvaraj
to make sure that the code only invoked this quirk on exynos and only
if a GPIO was not used

Re: [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc

[Doug Anderson]

Ulf,

On Wed, Aug 27, 2014 at 4:17 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 Now, we've got MMC_CAP_NEEDS_POLL, so dw_mmc will periodically be
 called to check the card detect line, but with vmmc and vqmmc off.  It
 will be unable to return a sensible value without actually turning on
 vmmc and vqmmc.

 Currently MMC_CAP_NEEDS_POLL mean the mmc rescan work will reschedule
 itself with HZ interval. This to check for card insert/removal.

 Now, mmc_rescan() will, if present, invoke host's -get_cd() callback
 to check whether it's worth to continue initialization sequence or if
 it should re-schedule itself again.

 If your host driver can distinguish whether a card is inserted, which
 in this case are when vccq is turned off, your -get_cd() callback need
 to return 1. That will allow mmc_rescan() to continue it's
 initialization sequence and do mmc_power_up().

As per my other email, we can't tell whether a card is inserted when
vqmmc is off.

Does this mean that you have removed your objections to a solution
like Yuvaraj has posted?  We still need to break it into two patches
(the core part and the dwmmc part), but otherwise is it OK?  I can
post the original patch I sent Yuvaraj if it's helpful (or he can just
include my patch as part 1 of his series).

-Doug
--
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 1/1] regulator: max77802: set opmode to normal if off is read from hw

[Doug Anderson]

Javier,

On Tue, Aug 26, 2014 at 4:37 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 The max77802 driver reads the default operating mode (opmode)
 set for regulators when enabled from the hardware registers.

 But if a regulator is disabled and the system warm restarted,
 the hardware reports OFF as the opmode so the regulator is
 not enabled. Default to operating mode NORMAL if OFF is read
 from the hardware register.

 Reported-by: Yuvaraj Cd yuvaraj.l...@gmail.com
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---

 This patch fixes the issue reported in https://lkml.org/lkml/2014/8/25/69

  drivers/regulator/max77802.c | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

 diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
 index ad1caa9..967e109 100644
 --- a/drivers/regulator/max77802.c
 +++ b/drivers/regulator/max77802.c
 @@ -540,7 +540,17 @@ static int max77802_pmic_probe(struct platform_device 
 *pdev)
 config.of_node = pdata-regulators[i].of_node;

 ret = regmap_read(iodev-regmap, regulators[i].enable_reg, 
 val);
 -   max77802-opmode[id] = val  shift  MAX77802_OPMODE_MASK;
 +   val = val  shift  MAX77802_OPMODE_MASK;
 +
 +   /*
 +* If the regulator is disabled and the system warm rebooted,
 +* the hardware reports OFF as the regulator operating mode.
 +* Default to operating mode NORMAL in that case.
 +*/
 +   if (val == MAX77802_OPMODE_OFF)
 +   max77802-opmode[id] = MAX77802_OPMODE_NORMAL;
 +   else
 +   max77802-opmode[id] = val;

Reviewed-by: Doug Anderson diand...@chromium.org
--
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 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc

[Doug Anderson]

Jaehoon,

On Tue, Aug 26, 2014 at 8:48 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
 Hi, Doug,

 On 08/26/2014 12:25 AM, Doug Anderson wrote:
 Jaehoon,

 On Mon, Aug 25, 2014 at 1:50 AM, Jaehoon Chung jh80.ch...@samsung.com 
 wrote:
 On 08/25/2014 05:13 PM, Ulf Hansson wrote:
 On 22 August 2014 20:27, Sonny Rao sonny...@chromium.org wrote:
 On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson ulf.hans...@linaro.org 
 wrote:
 On 22 August 2014 15:47, Yuvaraj Kumar C D yuvaraj...@gmail.com wrote:
 Exynos 5250 and 5420 based boards uses built-in CD# line for card
 detection.But unfortunately CD# line is on the same voltage rails
 as of I/O voltage rails. When we cut off vqmmc,the consequent card
 detection will break in these boards.

 I didn't know that use CD# line for card detect.
 And if CD# voltage rails and I/O voltage rail are same voltage, it doesn't 
 make sense.
 Which card is used with same voltages? (eMMC? SD? SDIO?)

 Well, I have checked Exynos5250 and 5420, but it looks like not same rails.

 I'm not sure I totally understood what you said.  In my manual I have
 a table titled Table 2-1 Exynos 5420 Pin List.  Look in this table
 for XMMC2CDN and XMMC2DATA_0.  Look to the right of the table and
 you'll see the power domain.  For both it shows VDDQ_MMC2.  If that
 doesn't mean that the two are in the same voltage domain then I don't
 know what does.  Can you point to any examples where they have
 different voltage domains?
 I think you're mis-understanding for it.
 Right, It's described at exynos5420, but it's not connected.

It's not connected.  What do you mean?  If I were to guess I'd say
that on some particular board you're looking at they don't happen to
use the CD pin for card detect.  If this is what you mean, it
doesn't help me.  exynos5420-peach-pit does use the CD pin for card
detect.  You can look at the DTS file and confirm it.

...or are you saying that the CD pin somehow changes voltage domains
when configured as a GPIO?  I find that very hard to believe.  What
voltage domain does it go to?  If it goes to a 1.8V voltage domain
then that would be bad when vqmmc was 3.3V.  If it goes to a 3.3V
voltage domain then that would be bad when vqmmc was 1.8V.  Remember
that externally we've got a pull up to vqmmc.

Even if somehow magically we can read the card detect pin with vqmmc
off, we have an external pullup on this line that goes directly to the
vqmmc power rail.  If the vqmmc power rail is off then this external
pull up would not work and would actually act as an external pull down
if you could somehow configure the internal line to be a pullup.


 Exynos4 series are also described, but we used the broken card detection 
 scheme and power used one of always-on powers.
 Because Card-detection rail need to enable as always-on.

 We don't need to consider this. I checked the circuit, this patch didn't need.

 exynos5 also used the gpio-pin for card-detection. And we can use the 
 slot-gpio API.

When you say exynos5, what do you mean here?  Do you mean the smdk
for 5250, or something else?
--
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 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators

[Doug Anderson]

Jaehoon,

On Mon, Aug 25, 2014 at 5:32 AM, Jaehoon Chung jh80.ch...@samsung.com wrote:
 On 08/22/2014 10:47 PM, Yuvaraj Kumar C D wrote:
 This patch makes use of mmc_regulator_get_supply() to handle
 the vmmc and vqmmc regulators.Also it moves the code handling
 the these regulators to dw_mci_set_ios().It turned on the vmmc
 and vqmmc during MMC_POWER_UP and MMC_POWER_ON,and turned off
 during MMC_POWER_OFF.

 Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
 ---
 changes from v1:
   1.Used mmc_regulator_set_ocr() instead of regulator_enable() for vmmc.
   2.Turned on vmmc and vqmmc during MMC_POWER_UP.
   3. Removed the flags DW_MMC_CARD_POWERED and DW_MMC_IO_POWERED which
  added during the initial version of this patch.
   4. Added error message, if it failed to turn on regulator's.

  drivers/mmc/host/dw_mmc.c  |   72 
 +---
  include/linux/mmc/dw_mmc.h |2 +-
  2 files changed, 36 insertions(+), 38 deletions(-)

 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
 index 7f227e9..aadb0d6 100644
 --- a/drivers/mmc/host/dw_mmc.c
 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -936,6 +936,7 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct 
 mmc_ios *ios)
   struct dw_mci_slot *slot = mmc_priv(mmc);
   const struct dw_mci_drv_data *drv_data = slot-host-drv_data;
   u32 regs;
 + int ret;

   switch (ios-bus_width) {
   case MMC_BUS_WIDTH_4:
 @@ -974,12 +975,38 @@ static void dw_mci_set_ios(struct mmc_host *mmc, 
 struct mmc_ios *ios)

   switch (ios-power_mode) {
   case MMC_POWER_UP:
 + if (!IS_ERR(mmc-supply.vmmc)) {
 + ret = mmc_regulator_set_ocr(mmc, mmc-supply.vmmc,
 + ios-vdd);
 + if (ret) {
 + dev_err(slot-host-dev,
 + failed to enable vmmc regulator\n);
 + /*return, if failed turn on vmmc*/
 + return;
 + }
 + }
 + if (!IS_ERR(mmc-supply.vqmmc)  !slot-host-vqmmc_enabled) {

 Can't use the regulator_is_enabled() instead of slot-host-vqmmc_enabled?

I think we mentioned this before, but regulator_is_enabled() won't do
what you want with shared regulators since they are refcounted.  You
need to keep track of whether you've enabled the regulator yourself.

-Doug
--
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 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc

[Doug Anderson]

Ulf,

On Mon, Aug 25, 2014 at 1:13 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 22 August 2014 20:27, Sonny Rao sonny...@chromium.org wrote:
 On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 22 August 2014 15:47, Yuvaraj Kumar C D yuvaraj...@gmail.com wrote:
 Exynos 5250 and 5420 based boards uses built-in CD# line for card
 detection.But unfortunately CD# line is on the same voltage rails
 as of I/O voltage rails. When we cut off vqmmc,the consequent card
 detection will break in these boards.

 I am not sure I follow here.

 Is the card detect mechanism handled internally by the dw_mmc controller?

 Yes

 Just out of curiosity.

 Do you know how the power to the actual dw_mmc controller is handled?
 I expect it to be SoC specific and I am guessing power domain
 regulators may be involved!?

You can likely read the dw_mmc registers when vqmmc is off.  Is that
what you're asking?  Certainly if vqmmc is not powered then the lines
themselves will be useless, won't they?  The vqmmc supply goes to
the VDDQ_MMC2 pin on 5420.  In my 5420 user manual, I see that
clk, cmd, cd, datN, wp and biuvr pins are all in this same
voltage (VDDQ_MMC2) domain.  Can you really read a pin without
powering that part of the SoC?


 I thought HW engineers long time ago realized that this should be done
 separately on a GPIO line to be able to save power while waiting for a
 card to be inserted. But that's not case then?

 At least in my limited experience, this seems to be common among SoC
 vendors who are using dw_mmc, as we've seen this elsewhere as well and
 after seeing it here we know that we need to ignore the CD pin that's
 routed to dw_mmc and use a separately powered GPIO on the board, but
 still there are probably many SoCs/boards which are doing it this way.


 These hosts (obviously) need to keep vqmmc (and thus vmmc) on all the
 time, even when the mmc core tells them to power off. However, one
 problem is that these cards won't properly handle mmc_power_cycle().
 That's needed to handle error cases when trying to switch voltages
 (see 0797e5f mmc:core: Fixup signal voltage switch).

 This patch adds a new MMC_POWER_OFF_HARD mode when it's doing a power
 cycle.  This mode differs from the normal MMC_POWER_OFF mode in that
 the mmc core will promise to power the slot back on before it expects
 the host to detect card insertion or removal.

 This patch is based off of one that Doug wrote (sent privately to
 Yuvaraj) which just modifies the MMC core, and should be split into
 two patches.
 One that modifies the mmc core and one that implements this in dw_mmc.

 I looked at the mmc core parts, it seems like the wrong approach.

 I think you shall be able use MMC_CAP_NEEDS_POLL, to handle this
 broken card detect mechanism. We even have a DT binding for that,
 broken-cd.

I don't think this is possible, but let me explain why I think so and
you can correct me.

The voltage domain of the card detect pin on the SoC is vqmmc,
right?  That means that you won't be able to read the pin without
turning on vqmmc.  Even if you could read the pin without turning on
vqmmc, the pullup on this line is connected to vqmmc too.  ...so if
vqmmc is off then there's no pulup and you can't use card detect.

Are you suggesting that we should flip the voltage of vqmmc (and thus
vmmc to prevent damaging the card) during polling?  That seems ugly.


One other thing to mention: we didn't find any power savings by
actually turning off vmmc and vqmmc when there was no card inserted.
There's no current running through the lines when there is no card
inserted and apparently everything is efficient enough that there was
no problem.

-Doug
--
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 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc

[Doug Anderson]

Jaehoon,

On Mon, Aug 25, 2014 at 1:50 AM, Jaehoon Chung jh80.ch...@samsung.com wrote:
 On 08/25/2014 05:13 PM, Ulf Hansson wrote:
 On 22 August 2014 20:27, Sonny Rao sonny...@chromium.org wrote:
 On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 22 August 2014 15:47, Yuvaraj Kumar C D yuvaraj...@gmail.com wrote:
 Exynos 5250 and 5420 based boards uses built-in CD# line for card
 detection.But unfortunately CD# line is on the same voltage rails
 as of I/O voltage rails. When we cut off vqmmc,the consequent card
 detection will break in these boards.

 I didn't know that use CD# line for card detect.
 And if CD# voltage rails and I/O voltage rail are same voltage, it doesn't 
 make sense.
 Which card is used with same voltages? (eMMC? SD? SDIO?)

 Well, I have checked Exynos5250 and 5420, but it looks like not same rails.

I'm not sure I totally understood what you said.  In my manual I have
a table titled Table 2-1 Exynos 5420 Pin List.  Look in this table
for XMMC2CDN and XMMC2DATA_0.  Look to the right of the table and
you'll see the power domain.  For both it shows VDDQ_MMC2.  If that
doesn't mean that the two are in the same voltage domain then I don't
know what does.  Can you point to any examples where they have
different voltage domains?

I agree that what exynos does is not sensible, but that's what it is.


 I am not sure I follow here.

 Is the card detect mechanism handled internally by the dw_mmc controller?

 Yes

 What card detect mechanism?

The dw_mmc controller has a way to read the card detect, right?
That's internal to the controller.  The alternative would be to use a
generic GPIO for card detect.
--
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 v9 1/2] regulator: Add driver for max77802 PMIC PMIC regulators

[Doug Anderson]

Javier,

On Mon, Aug 25, 2014 at 2:07 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 Hello Yuvaraj,

 On 08/25/2014 10:22 AM, Yuvaraj Cd wrote:
 Good question. I'm not that familiar with the dw_mmc host controller nor
 its driver implementation so I'll let Yuvaraj or Doug to answer that.
 Well,here it goes!
 1. Power ON the board LDO4CTRL1[7:6] 11b
 2. dw_mmc driver enable the vqmmc.
 3. checks for UHS support, complete the voltage switching t0 1.8V
 4. Does warm reset by reboot command.
 5. mmc core calls mmc_set_ios() with MMC_POWER_OFF.
 6. dw_mmc driver cut-off the regulator with LDO4CTRL1[7:6] is 00b
 7.dw_mmc driver enable the vqmmc.
  But after step 7 also, LD4CTRL[7:6] is 00b.

 Ok, so the dw_mmc driver is enabling vqmmc, that's good.


 I haven't seen the issue that Yuvaraj is reporting (but I also haven't
 picked up all of the relevant patches and tried to reproduce), so I'm
 going to have to leave it to Yuvaraj to answer.
 static int max77802_enable(struct regulator_dev *rdev)
 {
   struct max77802_regulator_prv *max77802 = rdev_get_drvdata(rdev);
  int id = rdev_get_id(rdev);
  int shift = max77802_get_opmode_shift(id);
  return regmap_update_bits(rdev-regmap,
 rdev-desc-enable_reg,rdev-desc-enable_mask,max77802-opmode[id] 
 shift);
   }
 I think in the above code snippet, the val is what we got it during
 the probe.We always write that value for enabling this regulator(which
 is LDO4CTRL1[7:6] 00b after warm reset) which is not correct according
 the MAX77802 manual.


 I see, so probably until we have a way to define the operating mode for
 each regulator using DT we should set the opmode to normal when enabling a
 regulator independently of the value the hardware register reported on probe.

 Can you please test the following change [0] so I can post as a proper
 patch? Doug, Mark do you think that forcing the regulator to opmode normal
 when enabling is the right solution here?

IMHO that makes sense.
--
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 2/3] mmc: dw_mmc: Support voltage changes

[Doug Anderson]

Ulf,

On Mon, Aug 25, 2014 at 1:31 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 22 August 2014 22:38, Doug Anderson diand...@google.com wrote:
 Ulf,

 On Fri, Aug 22, 2014 at 8:35 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 22 August 2014 15:47, Yuvaraj Kumar C D yuvaraj...@gmail.com wrote:
 From: Doug Anderson diand...@chromium.org

 For UHS cards we need the ability to switch voltages from 3.3V to
 1.8V.  Add support to the dw_mmc driver to handle this.  Note that
 dw_mmc needs a little bit of extra code since the interface needs a
 special bit programmed to the CMD register while CMD11 is progressing.
 This means adding a few extra states to the state machine to track.

 Signed-off-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
 ---
 changes since v1:
 1. Added error message and return error in case of 
 regulator_set_voltage() fail.
 2. changed  dw_mci_cmd_interrupt(host,pending | SDMMC_INT_CMD_DONE)
to dw_mci_cmd_interrupt(host,pending).
 3. Removed unnecessary comments.

  drivers/mmc/host/dw_mmc.c  |  134 
 +---
  drivers/mmc/host/dw_mmc.h  |5 +-
  include/linux/mmc/dw_mmc.h |2 +
  3 files changed, 131 insertions(+), 10 deletions(-)

 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
 index aadb0d6..f20b4b8 100644
 --- a/drivers/mmc/host/dw_mmc.c
 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -29,6 +29,7 @@
  #include linux/irq.h
  #include linux/mmc/host.h
  #include linux/mmc/mmc.h
 +#include linux/mmc/sd.h
  #include linux/mmc/sdio.h
  #include linux/mmc/dw_mmc.h
  #include linux/bitops.h
 @@ -234,10 +235,13 @@ err:
  }
  #endif /* defined(CONFIG_DEBUG_FS) */

 +static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg);
 +
  static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct 
 mmc_command *cmd)
  {
 struct mmc_data *data;
 struct dw_mci_slot *slot = mmc_priv(mmc);
 +   struct dw_mci *host = slot-host;
 const struct dw_mci_drv_data *drv_data = slot-host-drv_data;
 u32 cmdr;
 cmd-error = -EINPROGRESS;
 @@ -253,6 +257,31 @@ static u32 dw_mci_prepare_command(struct mmc_host 
 *mmc, struct mmc_command *cmd)
 else if (cmd-opcode != MMC_SEND_STATUS  cmd-data)
 cmdr |= SDMMC_CMD_PRV_DAT_WAIT;

 +   if (cmd-opcode == SD_SWITCH_VOLTAGE) {
 +   u32 clk_en_a;
 +
 +   /* Special bit makes CMD11 not die */
 +   cmdr |= SDMMC_CMD_VOLT_SWITCH;
 +
 +   /* Change state to continue to handle CMD11 weirdness */
 +   WARN_ON(slot-host-state != STATE_SENDING_CMD);
 +   slot-host-state = STATE_SENDING_CMD11;
 +
 +   /*
 +* We need to disable clock stop while doing voltage switch
 +* according to Voltage Switch Normal Scenario.
 +* It's assumed that by the next time the CLKENA is updated
 +* (when we set the clock next) that the voltage change 
 will
 +* be over, so we don't bother setting any bits to 
 synchronize
 +* with dw_mci_setup_bus().
 +*/

 I don't know the details about the dw_mmc controller, but normally a
 host driver is expected to gate the clock from it's -set_ios
 callback, when the clk frequency are set to 0.

 Could you elaborate on why dw_mmc can't do that, but need to handle
 this from here?

 Let's see, it's been a while since I wrote this...


 So dw_mmc has a special feature where the controller itself will
 automatically stop the MMC Card clock when nothing is going on.  This
 is called low power mode.  I'm not super familiar with other MMC
 drivers, I get the impression that this is a special dw_mmc feature
 and not common to other controllers.  I think other drivers have
 aggressive runtime PM to get similar power savings.

 I see.

 I am familiar with such low power mode features, there are certainly
 other controllers supporting such as well. My experience tells me,
 it's hard to get things right for all corner cases. The voltage switch
 behaviour is just one of these, then you have SDIO irq etc.

 Instead of using the controller HW, yes you may implement clock gating
 through runtime PM in the host driver.


 The dw_mmc auto clock gating can wreck total havoc on the voltage
 change procedure, since part of the way that the host and card
 communicate is that the host is supposed to stop its clock when it
 gets to a certain phase of the voltage switch sequence.  If the
 controller is stopping the clock for us then it can confuse the card.

 The dw_mmc manual says that before starting a voltage change you must
 turn off low power mode.  That's what we're doing here.


 The comment above refers to the fact dw_mci_setup_bus() will
 unconditionally turn low power mode back on for us when called with a
 non-zero clock.  If dw_mci_setup_bus() might be called

Re: [PATCH v7] ARM: dts: Prepare node labels for exynos5250

[Doug Anderson]

Kukjin,

On Fri, Aug 22, 2014 at 3:49 AM, Kukjin Kim kgene@samsung.com wrote:
 Andreas Färber wrote:

 Allows them to be extended by reference.

 Reviewed-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  v6 - v7:
  * Dropped uart* labels (Tomasz Figa)

  v6: Split off from Snow/SMDK cleanups (Doug Anderson)

  arch/arm/boot/dts/exynos5250.dtsi | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

 diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
 b/arch/arm/boot/dts/exynos5250.dtsi
 index 492e1eff37bd..42eafd19cfb2 100644
 --- a/arch/arm/boot/dts/exynos5250.dtsi
 +++ b/arch/arm/boot/dts/exynos5250.dtsi
 @@ -218,7 +218,7 @@
   clock-names = fimg2d;
   };

 - codec@1100 {
 + mfc: codec@1100 {
   compatible = samsung,mfc-v6;
   reg = 0x1100 0x1;
   interrupts = 0 96 0;
 @@ -227,7 +227,7 @@
   clock-names = mfc;
   };

 - rtc@101E {
 + rtc: rtc@101E {
   clocks = clock CLK_RTC;
   clock-names = rtc;
   status = disabled;
 @@ -261,7 +261,7 @@
   clock-names = uart, clk_uart_baud0;
   };

 - sata@122F {
 + sata: sata@122F {
   compatible = snps,dwc-ahci;
   samsung,sata-freq = 66;
   reg = 0x122F 0x1ff;
 @@ -573,7 +573,7 @@
   #phy-cells = 1;
   };

 - usb@1211 {
 + ehci: usb@1211 {

 I'm not sure which one is recommended between above and ehci: ehci@1211 
 {

My understanding is that more generic names should be used for node
names.  AKA: usb and not ehci.  mmc and not dwmmc.

In another thread I was pointed at ePAPR
http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf:

The name of a node should be somewhat generic, reflecting the function
of the device and not its precise programming model.


 - hdmi {
 + hdmi: hdmi {

 Should be

 +   hdmi: hdmi@1453 { ?

Seems like that should be a followon patch.
--
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 2/3] mmc: dw_mmc: Support voltage changes

[Doug Anderson]

Ulf,

On Fri, Aug 22, 2014 at 8:35 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 22 August 2014 15:47, Yuvaraj Kumar C D yuvaraj...@gmail.com wrote:
 From: Doug Anderson diand...@chromium.org

 For UHS cards we need the ability to switch voltages from 3.3V to
 1.8V.  Add support to the dw_mmc driver to handle this.  Note that
 dw_mmc needs a little bit of extra code since the interface needs a
 special bit programmed to the CMD register while CMD11 is progressing.
 This means adding a few extra states to the state machine to track.

 Signed-off-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
 ---
 changes since v1:
 1. Added error message and return error in case of 
 regulator_set_voltage() fail.
 2. changed  dw_mci_cmd_interrupt(host,pending | SDMMC_INT_CMD_DONE)
to dw_mci_cmd_interrupt(host,pending).
 3. Removed unnecessary comments.

  drivers/mmc/host/dw_mmc.c  |  134 
 +---
  drivers/mmc/host/dw_mmc.h  |5 +-
  include/linux/mmc/dw_mmc.h |2 +
  3 files changed, 131 insertions(+), 10 deletions(-)

 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
 index aadb0d6..f20b4b8 100644
 --- a/drivers/mmc/host/dw_mmc.c
 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -29,6 +29,7 @@
  #include linux/irq.h
  #include linux/mmc/host.h
  #include linux/mmc/mmc.h
 +#include linux/mmc/sd.h
  #include linux/mmc/sdio.h
  #include linux/mmc/dw_mmc.h
  #include linux/bitops.h
 @@ -234,10 +235,13 @@ err:
  }
  #endif /* defined(CONFIG_DEBUG_FS) */

 +static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg);
 +
  static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct mmc_command 
 *cmd)
  {
 struct mmc_data *data;
 struct dw_mci_slot *slot = mmc_priv(mmc);
 +   struct dw_mci *host = slot-host;
 const struct dw_mci_drv_data *drv_data = slot-host-drv_data;
 u32 cmdr;
 cmd-error = -EINPROGRESS;
 @@ -253,6 +257,31 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc, 
 struct mmc_command *cmd)
 else if (cmd-opcode != MMC_SEND_STATUS  cmd-data)
 cmdr |= SDMMC_CMD_PRV_DAT_WAIT;

 +   if (cmd-opcode == SD_SWITCH_VOLTAGE) {
 +   u32 clk_en_a;
 +
 +   /* Special bit makes CMD11 not die */
 +   cmdr |= SDMMC_CMD_VOLT_SWITCH;
 +
 +   /* Change state to continue to handle CMD11 weirdness */
 +   WARN_ON(slot-host-state != STATE_SENDING_CMD);
 +   slot-host-state = STATE_SENDING_CMD11;
 +
 +   /*
 +* We need to disable clock stop while doing voltage switch
 +* according to Voltage Switch Normal Scenario.
 +* It's assumed that by the next time the CLKENA is updated
 +* (when we set the clock next) that the voltage change will
 +* be over, so we don't bother setting any bits to 
 synchronize
 +* with dw_mci_setup_bus().
 +*/

 I don't know the details about the dw_mmc controller, but normally a
 host driver is expected to gate the clock from it's -set_ios
 callback, when the clk frequency are set to 0.

 Could you elaborate on why dw_mmc can't do that, but need to handle
 this from here?

Let's see, it's been a while since I wrote this...


So dw_mmc has a special feature where the controller itself will
automatically stop the MMC Card clock when nothing is going on.  This
is called low power mode.  I'm not super familiar with other MMC
drivers, I get the impression that this is a special dw_mmc feature
and not common to other controllers.  I think other drivers have
aggressive runtime PM to get similar power savings.

The dw_mmc auto clock gating can wreck total havoc on the voltage
change procedure, since part of the way that the host and card
communicate is that the host is supposed to stop its clock when it
gets to a certain phase of the voltage switch sequence.  If the
controller is stopping the clock for us then it can confuse the card.

The dw_mmc manual says that before starting a voltage change you must
turn off low power mode.  That's what we're doing here.


The comment above refers to the fact dw_mci_setup_bus() will
unconditionally turn low power mode back on for us when called with a
non-zero clock.  If dw_mci_setup_bus() might be called with a non-zero
clock during the voltage change then this would be disaster (low power
mode would be back on!).  ...but the clock will always be zero during
the voltage change and when it's finally non-zero then it's the last
stage of the voltage change and we can go back to low power mode.


Possibly the above was not super clear from the comment (even for
those familiar with the oddities of dw_mmc).  If you want me to try to
rewrite the comment, let me know.


-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body

Re: [PATCH v9 1/2] regulator: Add driver for max77802 PMIC PMIC regulators

[Doug Anderson]

Hi,

On Fri, Aug 22, 2014 at 3:02 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 Hello Mark,

 On 08/22/2014 08:30 PM, Mark Brown wrote:

 The problem is that one of these regulators is used as the vqmmc-supply
 (VCCQ/VDD_IO) so the mmc host controller driver disables it on
 MMC_POWER_OFF. Now AFAIK (Yuvaraj can correct me what I got wrong) this
 shouldn't be an issue since on card detection, the vqmmc supply should be
 enabled again but on Exynos the built-in card detect line is on the same
 power rail as vqmmc. That means that disabling the regulator prevents card
 insertions to be detected.

 If the MMC host controller needs a supply enabling in order to do card
 detection and it's supposed to be doing card detection I'd expect it to
 be enabling that supply.  Why is it not doing that?


 Good question. I'm not that familiar with the dw_mmc host controller nor
 its driver implementation so I'll let Yuvaraj or Doug to answer that.

I haven't seen the issue that Yuvaraj is reporting (but I also haven't
picked up all of the relevant patches and tried to reproduce), so I'm
going to have to leave it to Yuvaraj to answer.

As far as I know the dw_mmc driver ought to be enabling vqmmc when it
needs it.  Perhaps there's a bug in your patch series that adds vqmmc
support to dw_mmc?

-Doug
--
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 v7 02/11] power/restart: Call machine_restart instead of arm_pm_restart

[Doug Anderson]

Guenter,

On Wed, Aug 20, 2014 at 9:42 PM, Guenter Roeck li...@roeck-us.net wrote:
 On Wed, Aug 20, 2014 at 09:10:31PM -0700, Doug Anderson wrote:
 Guenter,

 On Tue, Aug 19, 2014 at 5:45 PM, Guenter Roeck li...@roeck-us.net wrote:
  machine_restart is supported on non-ARM platforms, and and ultimately calls
  arm_pm_restart, so dont call arm_pm_restart directly but use the more
  generic function.
 
  Cc: Russell King li...@arm.linux.org.uk

 Do you need to submit this to his patch tracker to get him to pick it
 up?  How are you envisioning that this series land?  It crosses a lot
 of boundaries so I guess will need a reasonable amount of coordination
 between maintainers...


 If I get an Acked-by: from all maintainers, I could send a pull request
 to Linus directly. How do I send a patch to Russell's patch tracker ?
 I thought I copied all mailing lists suggested by get_maintainer.pl,
 but maybe I missed one.

Ah, OK.  Perhaps it's best to ignore me, then.  ;)  FYI: Russell's
Patch System is at http://www.arm.linux.org.uk/developer/patches/
and is used for getting individual patches into branches maintained by
Russel.  If you're just going to send a pull request for the series
then I don't think you need it.
--
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: [RESEND PATCH 3/7] mfd: cros_ec: stop calling -cmd_xfer() directly

[Doug Anderson]

Javier,

On Wed, Aug 20, 2014 at 5:13 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 From: Andrew Bresticker abres...@chromium.org

 Instead of having users of the ChromeOS EC call the interface-specific
 cmd_xfer() callback directly, introduce a central cros_ec_cmd_xfer()
 to use instead.  This will allow us to put all the locking and retry
 logic in one place instead of duplicating it across the different
 drivers.

 Signed-off-by: Andrew Bresticker abres...@chromium.org
 Reviewed-by: Simon Glass s...@chromium.org
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  drivers/i2c/busses/i2c-cros-ec-tunnel.c |  2 +-
  drivers/input/keyboard/cros_ec_keyb.c   |  2 +-
  drivers/mfd/cros_ec.c   |  7 +++
  include/linux/mfd/cros_ec.h | 24 ++--
  4 files changed, 27 insertions(+), 8 deletions(-)

Reviewed-by: Doug Anderson diand...@chromium.org
--
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 v7 02/11] power/restart: Call machine_restart instead of arm_pm_restart

[Doug Anderson]

Guenter,

On Tue, Aug 19, 2014 at 5:45 PM, Guenter Roeck li...@roeck-us.net wrote:
 machine_restart is supported on non-ARM platforms, and and ultimately calls
 arm_pm_restart, so dont call arm_pm_restart directly but use the more
 generic function.

 Cc: Russell King li...@arm.linux.org.uk

Do you need to submit this to his patch tracker to get him to pick it
up?  How are you envisioning that this series land?  It crosses a lot
of boundaries so I guess will need a reasonable amount of coordination
between maintainers...


 Signed-off-by: Guenter Roeck li...@roeck-us.net
 Acked-by: Catalin Marinas catalin.mari...@arm.com
 Acked-by: Heiko Stuebner he...@sntech.de
 ---
 v7: No change.
 v6: No change.
 v5: No change.
 v4: No change.
 v3: No change.
 v2: Added patch.

  drivers/power/reset/restart-poweroff.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Doug Anderson diand...@chromium.org
Tested-by: Doug Anderson diand...@chromium.org
--
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 v7 04/11] arm: Support restart through restart handler call chain

[Doug Anderson]

Guenter,

On Tue, Aug 19, 2014 at 5:45 PM, Guenter Roeck li...@roeck-us.net wrote:
 The kernel core now supports a restart handler call chain for system
 restart functions.

 With this change, the arm_pm_restart callback is now optional, so
 drop its initialization and check if it is set before calling it.
 Only call the kernel restart handler if arm_pm_restart is not set.

 Signed-off-by: Guenter Roeck li...@roeck-us.net
 Acked-by: Catalin Marinas catalin.mari...@arm.com
 Acked-by: Heiko Stuebner he...@sntech.de
 ---
 v7: Dropped null_restart and made arm_pm_restart truly optional.
 v6: No change.
 v5: Renamed restart function to do_kernel_restart
 v4: No change.
 v3: Use wrapper function to execute notifier call chain.
 v2: Only call notifier call chain if arm_pm_restart is not set.
 Do not include linux/watchdog.h.

  arch/arm/kernel/process.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

Reviewed-by: Doug Anderson diand...@chromium.org
Tested-by: Doug Anderson diand...@chromium.org
--
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 v7 08/11] arm/arm64: Unexport restart handlers

[Doug Anderson]

Guenter,

On Tue, Aug 19, 2014 at 5:45 PM, Guenter Roeck li...@roeck-us.net wrote:
 Implementing a restart handler in a module don't make sense
 as there would be no guarantee that the module is loaded when
 a restart is needed. Unexport arm_pm_restart to ensure that
 no one gets the idea to do it anyway.

 Signed-off-by: Guenter Roeck li...@roeck-us.net
 Acked-by: Catalin Marinas catalin.mari...@arm.com
 Acked-by: Heiko Stuebner he...@sntech.de
 ---
 v7: No change
 v6: No change
 v5: No change
 v4: No change
 v3: No change
 v2: No change

  arch/arm/kernel/process.c   | 1 -
  arch/arm64/kernel/process.c | 1 -
  2 files changed, 2 deletions(-)

Reviewed-by: Doug Anderson diand...@chromium.org
Tested-by: Doug Anderson diand...@chromium.org

(FYI: all patches tested by me were tested on rk3288-evb)
--
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 v7 03/11] arm64: Support restart through restart handler call chain

[Doug Anderson]

Guenter,

On Tue, Aug 19, 2014 at 5:45 PM, Guenter Roeck li...@roeck-us.net wrote:
 The kernel core now supports a restart handler call chain to restart
 the system. Call it if arm_pm_restart is not set.

 Signed-off-by: Guenter Roeck li...@roeck-us.net
 Acked-by: Catalin Marinas catalin.mari...@arm.com
 Acked-by: Heiko Stuebner he...@sntech.de
 ---
 v7: No change.
 v6: No change.
 v5: Renamed restart function to do_kernel_restart
 v4: No change.
 v3: Use wrapper function to execute notifier call chain.
 v2: Only call notifier call chain if arm_pm_restart is not set.
 Do not include linux/watchdog.h.

  arch/arm64/kernel/process.c | 2 ++
  1 file changed, 2 insertions(+)

Reviewed-by: Doug Anderson diand...@chromium.org
--
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 v7 11/11] clk: rockchip: add restart handler

[Doug Anderson]

Guenter / Heiko,

On Tue, Aug 19, 2014 at 5:45 PM, Guenter Roeck li...@roeck-us.net wrote:
 From: Heiko Stübner he...@sntech.de

 Add infrastructure to write the correct value to the restart register and
 register the restart notifier for both rk3188 (including rk3066) and rk3288.

 Signed-off-by: Heiko Stuebner he...@sntech.de
 Signed-off-by: Guenter Roeck li...@roeck-us.net
 ---
 v7: Added patch to series.

  drivers/clk/rockchip/clk-rk3188.c |  2 ++
  drivers/clk/rockchip/clk-rk3288.c |  2 ++
  drivers/clk/rockchip/clk.c| 25 +
  drivers/clk/rockchip/clk.h|  1 +
  4 files changed, 30 insertions(+)

This patch doesn't apply cleanly with the in-flight (clk: rockchip:
protect critical clocks from getting disabled) patch from Heiko.  It's
trivial to resolve and unclear which will land first, so I think it's
fine...

Reviewed-by: Doug Anderson diand...@chromium.org
Tested-by: Doug Anderson diand...@chromium.org

(FYI: all patches tested by me were tested on rk3288-evb)
--
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] ARM: dts: Add vmmc and vqmmc supplies for Peach Pit and Pi boards

[Doug Anderson]

Javier,

On Tue, Aug 19, 2014 at 8:08 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 The VCC/VDD and VCCQ/VDD_IO power supplies for the MMC are
 provided by the tps65090 fet4 and max77802 ldo4 regulators
 respectively. Add the phandle to the regulators tree nodes
 for the the dw_mmc device device.

 These DTS snippets were taken from the downstream ChromeOS
 3.8 kernel Device Tree for Peach Pit and Pi boards.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/exynos5420-peach-pit.dts | 2 ++
  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 2 ++
  2 files changed, 4 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
 b/arch/arm/boot/dts/exynos5420-peach-pit.dts
 index 8e50042..5b9dbb9 100644
 --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
 +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
 @@ -547,6 +547,8 @@
  };

  mmc_2 {
 +   vmmc-supply = tps65090_fet4;
 +   vqmmc-supply = vqmmc_sdcard;
 status = okay;
 num-slots = 1;
 supports-highspeed;
 diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
 b/arch/arm/boot/dts/exynos5800-peach-pi.dts
 index 939f91c..dcac443 100644
 --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
 +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
 @@ -545,6 +545,8 @@
  };

  mmc_2 {
 +   vmmc-supply = tps65090_fet4;
 +   vqmmc-supply = vqmmc_sdcard;
 status = okay;
 num-slots = 1;
 supports-highspeed;

While your change is correct, I have a worry that it will break things
if it's merged before some patches that Yuvaraj is working on.

Specifically the problem on pit and pi (and any exynos5250 / 5420 /
5800 / ... boards using the built-in card detect) is that the card
detect line is on the same power rail as vqmmc.  That means you
can't turn off vqmmc if you still need to be able to detect card
insertions.

...but you can't turn off vmmc without turning off vqmmc, otherwise
current will leak through the IO lines into the card, which is bad.


Right now the SDMMC core will try to turn off power to the card at two times:
1. when the card is ejected
2. when it's trying to reset the card


Obviously the first problem is a huge problem on exynos because it
means that we won't be able to detect card insertions.  ...but we
still want to turn the power off from #2.  To really fix the problem I
think the core needs to be extended to treat the above as two separate
cases.


Your patch might work at the moment because I think dw_mmc doesn't
actually try to turn off these rails with the main SDMMC core asks it
to.  ...but I still worry about merging them before Yuvaraj's changes
are ready.


-Doug
--
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] mmc: dw_mmc: Make sure we don't get stuck when we get an error

[Doug Anderson]

Hi,

On Wed, May 21, 2014 at 2:08 AM, Seungwon Jeon tgih@samsung.com wrote:
 On Wed, May 21, 2014, Doug Anderson wrote:
 If we happened to get a data error at just the wrong time the dw_mmc
 driver could get into a state where it would never complete its
 request.  That would leave the caller just hanging there.

 We fix this two ways and both of the two fixes on their own appear to
 fix the problems we've seen:

 1. Fix a race in the tasklet where the interrupt setting the data
error happens _just after_ we check for it, then we get a
EVENT_XFER_COMPLETE.  We fix this by repeating a bit of code.
 2. Fix it so that if we detect that we've got an error in the data
busy state and we're not going to do anything else we end the
request and unblock anyone waiting.

 Signed-off-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Yuvaraj Kumar C D yuvaraj...@gmail.com

 It will be applied after mmc: dw_mmc: change to use recommended reset 
 procedure

 Acked-by: Seungwon Jeon tgih@samsung.com

 Thanks,
 Seungwon Jeon

I saw that Ulf applied mmc: dw_mmc: change to use recommended reset
procedure.  Could we apply this one now, too?  Do you want me to
repost?

-Doug
--
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

[REPOST PATCH v2] mmc: dw_mmc: Make sure we don't get stuck when we get an error

[Doug Anderson]

If we happened to get a data error at just the wrong time the dw_mmc
driver could get into a state where it would never complete its
request.  That would leave the caller just hanging there.

We fix this two ways and both of the two fixes on their own appear to
fix the problems we've seen:

1. Fix a race in the tasklet where the interrupt setting the data
   error happens _just after_ we check for it, then we get a
   EVENT_XFER_COMPLETE.  We fix this by repeating a bit of code.
2. Fix it so that if we detect that we've got an error in the data
   busy state and we're not going to do anything else we end the
   request and unblock anyone waiting.

Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@gmail.com
Acked-by: Seungwon Jeon tgih@samsung.com
---
Changes in v2:
- Removed TODO
- Set cmd to NULL before calling dw_mci_request_end()

 drivers/mmc/host/dw_mmc.c | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 8f216ed..7f227e9 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1299,6 +1299,14 @@ static void dw_mci_tasklet_func(unsigned long priv)
/* fall through */
 
case STATE_SENDING_DATA:
+   /*
+* We could get a data error and never a transfer
+* complete so we'd better check for it here.
+*
+* Note that we don't really care if we also got a
+* transfer complete; stopping the DMA and sending an
+* abort won't hurt.
+*/
if (test_and_clear_bit(EVENT_DATA_ERROR,
   host-pending_events)) {
dw_mci_stop_dma(host);
@@ -1312,7 +1320,29 @@ static void dw_mci_tasklet_func(unsigned long priv)
break;
 
set_bit(EVENT_XFER_COMPLETE, host-completed_events);
+
+   /*
+* Handle an EVENT_DATA_ERROR that might have shown up
+* before the transfer completed.  This might not have
+* been caught by the check above because the interrupt
+* could have gone off between the previous check and
+* the check for transfer complete.
+*
+* Technically this ought not be needed assuming we
+* get a DATA_COMPLETE eventually (we'll notice the
+* error and end the request), but it shouldn't hurt.
+*
+* This has the advantage of sending the stop command.
+*/
+   if (test_and_clear_bit(EVENT_DATA_ERROR,
+  host-pending_events)) {
+   dw_mci_stop_dma(host);
+   send_stop_abort(host, data);
+   state = STATE_DATA_ERROR;
+   break;
+   }
prev_state = state = STATE_DATA_BUSY;
+
/* fall through */
 
case STATE_DATA_BUSY:
@@ -1335,6 +1365,22 @@ static void dw_mci_tasklet_func(unsigned long priv)
/* stop command for open-ended transfer*/
if (data-stop)
send_stop_abort(host, data);
+   } else {
+   /*
+* If we don't have a command complete now we'll
+* never get one since we just reset everything;
+* better end the request.
+*
+* If we do have a command complete we'll fall
+* through to the SENDING_STOP command and
+* everything will be peachy keen.
+*/
+   if (!test_bit(EVENT_CMD_COMPLETE,
+ host-pending_events)) {
+   host-cmd = NULL;
+   dw_mci_request_end(host, mrq);
+   goto unlock;
+   }
}
 
/*
-- 
2.1.0.rc2.206.gedb03e5

--
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 3/6] ARM: dts: Create cros-tps65090 fragment

[Doug Anderson]

Javier,

On Tue, Aug 12, 2014 at 9:44 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 The tps65090 PMU is a component used in many ChromeOS devices
 so instead of having the same device tree definitions in many
 files, create a .dtsi fragment that can be included in DTS.

 This fragment is based on the DT definitions for Peach boards.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/cros-tps65090.dtsi | 81 
 
  1 file changed, 81 insertions(+)
  create mode 100644 arch/arm/boot/dts/cros-tps65090.dtsi

I'd probably skip this patch (just have duplication in pit vs. pi), or
make it peach specific (like exynos-peach-tps65090.dtsi?).  This is
really board-specific info and trying to guess what the various FETs
are going to be for for all peach variants doesn't seem great.

-Doug
--
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: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support

[Doug Anderson]

Javier,

On Mon, Aug 11, 2014 at 4:06 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 Many Exynos5 boards (e.g: Snow, Peach Pit and Pi) have
 a SBS-compliant gas gauge battery. Enable it as module
 so the needed support is available for these boards.

 Suggested-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Acked-by: Kukjin Kim kgene@samsung.com
 ---
  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..c390bb9 100644
 --- a/arch/arm/configs/exynos_defconfig
 +++ b/arch/arm/configs/exynos_defconfig
 @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y
  CONFIG_I2C_S3C2410=y
  CONFIG_DEBUG_GPIO=y
  CONFIG_POWER_SUPPLY=y
 +CONFIG_BATTERY_SBS=m
  CONFIG_CHARGER_TPS65090=y
  # CONFIG_HWMON is not set
  CONFIG_THERMAL=y

I'm good with this, so:

Reviewed-by: Doug Anderson diand...@chromium.org

To address Bartlomiej: =m is what's in ChromeOS for exynos, though I
notice that other platforms in the ChromeOS tree have =y.  I'm not
sure why there is a difference, but it's probably just carelessness.

Normally in ChromeOS we use =m for drivers that can afford to wait
until after the UI is up and running.  That helps improve boot time
since the user can use the device sooner (and it's OK if the battery
driver takes a few extra seconds to load).  The only things that
really should be =y are drivers that are critical to load early or
that are needed for the user to interact with the system.  In this
case you could argue that loading sbs earlier means that if the system
is low on battery it will get back to shutdown sooner.  I'm not sure
getting the shutdown a few seconds earlier is really critical,
though...

-Doug
--
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: [RESEND PATCH 1/2] ARM: dts: Improve Peach Pit and Pi power scheme

[Doug Anderson]

Javier,

On Mon, Aug 11, 2014 at 4:38 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 The DeviceTree files for the Peach Pit and Pi machines have
 a simplistic model of the connections between the different
 regulators since not all the tps65090 regulators get their
 input supply voltage from the VDC. DCDC1-3, LD0-1 and fet7
 parent supply is indded VDC but the fet1-6 get their input
 supply from the DCDC1 and DCDC2 output voltage rails.

 Update the DeviceTree to better reflect the real connections
 between tps65090 regulators. Having this information in the
 DTS is useful since FETs are switches that don't provide an
 output voltage so the regulator core needs to fetch the FET
 parent output voltage if the child voltage is queried.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Acked-by: Mark Brown broo...@linaro.org
 ---
  arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 ++--
  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 12 ++--
  2 files changed, 12 insertions(+), 12 deletions(-)

Matches my schematics.  Kukjin: I think this could be applied to
for-next whenever it's convenient.

Acked-by: Doug Anderson diand...@chromium.org
--
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: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support

[Doug Anderson]

Bartlomiej,

On Mon, Aug 11, 2014 at 8:42 AM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:

 Hi,

 On Monday, August 11, 2014 02:52:27 PM Javier Martinez Canillas wrote:
 Hello Bartlomiej,

 On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote:
  index fc7d168..c390bb9 100644
  --- a/arch/arm/configs/exynos_defconfig
  +++ b/arch/arm/configs/exynos_defconfig
  @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y
   CONFIG_I2C_S3C2410=y
   CONFIG_DEBUG_GPIO=y
   CONFIG_POWER_SUPPLY=y
  +CONFIG_BATTERY_SBS=m
 
  Why not make it =y?
 
  Rationale:
  - currently no hardware related option uses =m in exynos_defconfig
  - it would match the SBS option usage in multi_v7_defconfig
 
   CONFIG_CHARGER_TPS65090=y
   # CONFIG_HWMON is not set
   CONFIG_THERMAL=y
 

 I know but personally I think this should be changed. The idea of having a 
 multi
 platform kernel is to build a single kernel image that can be used to boot
 different platforms. Not all platforms have a SBS-compliant battery so this
 support shouldn't be built in the kernel image IMHO.

 This also matches to what real users will do since distributions most likely
 will have a minimal kernel and every possible hardware support will be 
 enabled
 as a loadable kernel module. This is what distros do for other platforms too.

 If someone has a different use case and wants a kernel image that is 
 optimized
 for a particular platform then she has to create its own defconfig anyways.

 Distributions usually use their own configs anyway and the current most
 popular use case for exynos_defconfig (not multi_v7_defconfig) seems to
 be to build kernel image alone and use it without any modules:

 $ grep =m arch/arm/configs/exynos_defconfig
 CONFIG_DM_CRYPT=m

 $ grep =m .config
 CONFIG_NET_IP_TUNNEL=m
 CONFIG_INET_TUNNEL=m
 CONFIG_IPV6=m
 CONFIG_INET6_XFRM_MODE_TRANSPORT=m
 CONFIG_INET6_XFRM_MODE_TUNNEL=m
 CONFIG_INET6_XFRM_MODE_BEET=m
 CONFIG_IPV6_SIT=m
 CONFIG_DM_CRYPT=m
 CONFIG_CRYPTO_RNG=m
 CONFIG_CRYPTO_ANSI_CPRNG=m

 What I'm trying to say is that there is a high probability that people
 will continue to use just the kernel image for exynos_defconfig and
 will therefore miss SBS battery support altogether (which is only 3.6
 kB of code more in the kernel image so there is no much gain in making
 it modular currently).

I'm not against making it =y for exynos_defconfig.  I do pretty
strongly agree that the multi_v7 version should be =m eventually,
though.  We'd need to do everything we can to make that kernel
smaller.

-Doug
--
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: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support

[Doug Anderson]

Hi,

On Mon, Aug 11, 2014 at 10:28 AM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:

 Hi,

 On Monday, August 11, 2014 06:23:01 PM Javier Martinez Canillas wrote:
 Hello,

 On 08/11/2014 05:59 PM, Doug Anderson wrote:
  Bartlomiej,
 
  On Mon, Aug 11, 2014 at 8:42 AM, Bartlomiej Zolnierkiewicz
  b.zolnier...@samsung.com wrote:
 
  Hi,
 
  On Monday, August 11, 2014 02:52:27 PM Javier Martinez Canillas wrote:
  Hello Bartlomiej,
 
  On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote:
   index fc7d168..c390bb9 100644
   --- a/arch/arm/configs/exynos_defconfig
   +++ b/arch/arm/configs/exynos_defconfig
   @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y
CONFIG_I2C_S3C2410=y
CONFIG_DEBUG_GPIO=y
CONFIG_POWER_SUPPLY=y
   +CONFIG_BATTERY_SBS=m
  
   Why not make it =y?
  
   Rationale:
   - currently no hardware related option uses =m in exynos_defconfig
   - it would match the SBS option usage in multi_v7_defconfig
  
CONFIG_CHARGER_TPS65090=y
# CONFIG_HWMON is not set
CONFIG_THERMAL=y
  
 
  I know but personally I think this should be changed. The idea of having 
  a multi
  platform kernel is to build a single kernel image that can be used to 
  boot
  different platforms. Not all platforms have a SBS-compliant battery so 
  this
  support shouldn't be built in the kernel image IMHO.
 
  This also matches to what real users will do since distributions most 
  likely
  will have a minimal kernel and every possible hardware support will be 
  enabled
  as a loadable kernel module. This is what distros do for other platforms 
  too.
 
  If someone has a different use case and wants a kernel image that is 
  optimized
  for a particular platform then she has to create its own defconfig 
  anyways.
 
  Distributions usually use their own configs anyway and the current most
  popular use case for exynos_defconfig (not multi_v7_defconfig) seems to
  be to build kernel image alone and use it without any modules:
 
  $ grep =m arch/arm/configs/exynos_defconfig
  CONFIG_DM_CRYPT=m
 
  $ grep =m .config
  CONFIG_NET_IP_TUNNEL=m
  CONFIG_INET_TUNNEL=m
  CONFIG_IPV6=m
  CONFIG_INET6_XFRM_MODE_TRANSPORT=m
  CONFIG_INET6_XFRM_MODE_TUNNEL=m
  CONFIG_INET6_XFRM_MODE_BEET=m
  CONFIG_IPV6_SIT=m
  CONFIG_DM_CRYPT=m
  CONFIG_CRYPTO_RNG=m
  CONFIG_CRYPTO_ANSI_CPRNG=m
 
  What I'm trying to say is that there is a high probability that people
  will continue to use just the kernel image for exynos_defconfig and
  will therefore miss SBS battery support altogether (which is only 3.6
  kB of code more in the kernel image so there is no much gain in making
  it modular currently).
 
  I'm not against making it =y for exynos_defconfig.  I do pretty
  strongly agree that the multi_v7 version should be =m eventually,
  though.  We'd need to do everything we can to make that kernel
  smaller.
 

 Same for me. I don't have such a strong opinion about this so if you think 
 that
 I should re-spin to change to =m, I will.

 I do think that we should try to keep the delta between exynos_defconfig and
 multi_v7_defconfig as small as possible and eventually even get rid of
 exynos_defconfig. Since building everything as built-in and having a config

 I completely agree.  I proposed exynos_defconfig removal as soon as
 Exynos gained multiplatform support (and before exynos_defconfig
 started getting out-of-sync with multi_v7_defconfig).  There were
 arguments that it is still useful in some cases.  I think that if
 it would be possible to go from a modular multi_v7_defconfig to
 a modular/built-in single platform config (using a script?) all
 such use cases will be covered.

There's one really nice thing about having an exynos_defconfig.  It
makes it a little easier to tease apart what's actually needed if you
just want to build a product kernel that support exynos.

Most product kernels shipping in embedded devices only support one or
maybe a small number of SoCs.  If you need to try to figure out what
parts of the multi_v7 config is relevant then it's very hard.

It's also nice to help measure multiplatform code bloat.  You can keep
measuring the output kernel size of the exynos kernel to see how much
bloat all of the mutliplatform stuff has added.


 so I would vote for CONFIG_BATTERY_SBS=y for both configs.  Especially
 since it results in only 3.6 kB bigger kernel image (0.05% kernel size
 increase for kernel image built with exynos_defconfig, probably a lot
 less for multi_v7_defconfig one).

Death by 1000 cuts is a very painful death indeed, even if each cut is small.

-Doug
--
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 1/1] Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting

[Doug Anderson]

Hi,

On Fri, Aug 8, 2014 at 11:29 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 Hello,

 On 08/08/2014 06:38 PM, Javier Martinez Canillas wrote:


 It seems as if the first call to exynos_irq_set_type() that is made by OF is 
 a
 no-op while the second call is the one that actually setups the hw correctly.
 Does this make any sense? Maybe is related to the pin not being muxed in the
 correct function when the interrupts property is parsed by OF?


 So after a conversation with Tomasz Figa over IRC the problem was after all 
 that
 the pin was reconfigured. The IRQ trigger type resulted to be just a red 
 herring
 and not a direct cause.

 The pinctrl-eyxnos driver does the IRQ pinmux setup in the .irq_set_type
 function handler. So what happened was that OF parsed the interrupts 
 property
 and called exynos_irq_set_type() which did the pinmux setup.

 But after that, due a DTS pinctrl configuration the pin function was changed 
 as
 a GPIO input and that happened before the atmel driver was probed. So when the
 driver called request_threaded_irq(), the correct flags were used but the pin
 was not configured as an IRQ anymore so IRQ were not fired.

 Setting a trigger type just had the side effect of calling 
 exynos_irq_set_type()
 which again setup the pin as an IRQ.

 To fix the issue a variation of patch [0] will be posted that moves the IRQ
 pinmux setup from .irq_set_type to the .irq_request_resources function 
 handler.
 That way the pin will be setup as IRQ regardless of the the trigger type [1]
 when someone calls request_[threaded]_irq().

 Only the mentioned patch fixes the issue but Tomasz said that even a call to
 gpio_direction_{input,output} can change the pin configuration so he will post
 another patch that will add a bit mask to samsung_pin_bank to prevent any 
 pinmux
 reconfiguration.

Would just making a device tree change fix this?  AKA for the pin, do:

  samsung,pin-function = 0xf;

I have some vague recollection that I set interrupts to pin-function
0 by default for some reason (assuming they would go to 0xf when
interrupts were enabled).  ...but I can't for the life of me remember
if it was a good reason or just seemed like the right thing to do.

-Doug
--
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 1/1] Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting

[Doug Anderson]

Javier,

On Fri, Aug 8, 2014 at 3:26 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 I have some vague recollection that I set interrupts to pin-function
 0 by default for some reason (assuming they would go to 0xf when
 interrupts were enabled).  ...but I can't for the life of me remember
 if it was a good reason or just seemed like the right thing to do.


 It would be great to know if there is a good reason. I see indeed that all
 pinctrl setup in the Peach Pit/Pi and Snow DTS that involves interrupts are
 using 0x0 as the pin function. Since as Tomasz explained Samsung SoC makes a
 difference between GPIO-IRQ and GPIO input I guess that it's better to change
 those to 0xf instead. What do you think?

I think it's worth trying out.  If there are no problems with it then
let's do it.

My vague recollection is that I was worried that pinctrl would take
effect right at driver probe time (maybe this used to happen? or maybe
I imagined it?) and that configuring to 0xf at this point in time
would cause a spurious interrupt.  I can't remember ever testing it so
it was probably just something I imagined.  Even if it was configured
as 0xf I'd imagine that the interrupt would be masked anyway so there
should be no spurious interrupt, right?


 Regardless of this though I think that both the patch to move the IRQ
 pinmux setup from .irq_set_type to the .irq_request_resources and the patch to
 to prevent any pinmux reconfiguration are good improvements to avoid future
 issues like the one we found here.

OK.  I'll let you, Tomasz, and Linus figure out what's best here since
I haven't done extensive thinking on it.  ;)

-Doug
--
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 1/1] ARM: dts: Add Peach Pit and Pi dts entry for atmel touchpad

[Doug Anderson]

Fabio,

On Wed, Aug 6, 2014 at 6:35 PM, Fabio Estevam feste...@gmail.com wrote:
 On Wed, Aug 6, 2014 at 10:08 PM, Javier Martinez Canillas
 javier.marti...@collabora.co.uk wrote:

 +hsi2c_8 {
 +   status = okay;
 +   clock-frequency = 333000;

 Doesn't it work at the more standard 400kHz i2c frequency?

I'm pretty sure that they had signaling problems at 400kHz, but
perhaps Benson will rememer.
--
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 v6 10/10] ARM: dts: Add exynos5250-spring device tree

[Doug Anderson]

Andreas,

On Fri, Aug 1, 2014 at 5:52 PM, Andreas Färber afaer...@suse.de wrote:
 Adds initial support for the HP Chromebook 11.

 Cc: Vincent Palatin vpala...@chromium.org
 Cc: Doug Anderson diand...@chromium.org
 Cc: Stephan van Schaik step...@synkhronix.com
 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  v5 - v6:
  * Updated for mfc node label
  * Reverted to dp-hpd-gpio node in pinctrl_0 (Doug Anderson)
  * Fixed alphabetical order of sd1_* nodes (Doug Anderson)

  v4 - v5:
  * Dropped bogus USB3 regulator (Vincent Palatin, Tomasz Figa)
  * Fixed USB3503 reset GPIO (Tomasz Figa)
  * Introduced labels to use new referencing style consistently (Tomasz Figa)
  * Don't override dp_hpd, moved to pinctrl_0 instead (Tomasz Figa)
  * mmc_1: Added comment from Snow's mmc_3 (Tomasz Figa / Doug Anderson)
  * Override /codec samsung,mfc-{l,r} properties for alignment with Arndale
  * Use more GPIO_ACTIVE_* constants
  * Use IRQ_TYPE_* constants
  * Dropped s5m_ prefix for s5m8767 LDO regulator labels (max77686 is gone)
  * Labeled also all s5m8767 BUCK regulators

  v3 - v4:
  * Fixed samsung,pin-function 1 - 0 for dp-hpd-gpio
  * Replaced dp-hpd-gpio with existing dp_hpd, overriding it

  v2 - v3:
  * Use GPIO_ACTIVE_{LOW,HIGH} (Doug Anderson)
  * Use symbolic KEY_POWER instead of comment
  * Moved hsic_reset to new USB3503 node's reset-gpios (Vincent Palatin)
  * Use dp_hpd_gpio for dp-controller (Doug Anderson, Ajay Kumar)
  * Override sd1_{clk,cmd,cd,bus4} pinctrl similar to Snow (Doug Anderson)
  * Added ec_irq pinctrl for cros_ec (Doug Anderson)
  * Reordered nodes to minimize diff against Snow (Doug Anderson)
  * Dropped obsolete mmc_2 override (Doug Anderson)
  * Added lid-switch node (Doug Anderson)
  * Added gpio-keys pinctrl (Doug Anderson)
  * Added bootargs to avoid empty /chosen node and to document console setting
  * Renamed s5m8767_pmic node to avoid underscore
  * Use new style for overriding inherited pinctrl nodes, too
  * Enable i2s0 node

  v1 - v2:
  * Use label-based overriding/extension of nodes. (Doug Anderson)
  * Dropped tps65090 for now, until we know where to place it.
  * Dropped non-Spring nodes from -cros-common.dtsi rather than disabling them.
  * Enabled a missing MMC node for access to internal storage.
  * Dropped display-timings from dp-controller node. (Ajay Kumar)

  arch/arm/boot/dts/Makefile  |   1 +
  arch/arm/boot/dts/exynos5250-spring.dts | 536 
 
  2 files changed, 537 insertions(+)
  create mode 100644 arch/arm/boot/dts/exynos5250-spring.dts

 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 80a781f76e88..dec4c292f63d 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -76,6 +76,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
 exynos5250-arndale.dtb \
 exynos5250-smdk5250.dtb \
 exynos5250-snow.dtb \
 +   exynos5250-spring.dtb \
 exynos5260-xyref5260.dtb \
 exynos5410-smdk5410.dtb \
 exynos5420-arndale-octa.dtb \
 diff --git a/arch/arm/boot/dts/exynos5250-spring.dts 
 b/arch/arm/boot/dts/exynos5250-spring.dts
 new file mode 100644
 index ..f5566f84d885
 --- /dev/null
 +++ b/arch/arm/boot/dts/exynos5250-spring.dts
 @@ -0,0 +1,536 @@
 +/*
 + * Google Spring board device tree source
 + *
 + * Copyright (c) 2013 Google, Inc
 + * Copyright (c) 2014 SUSE LINUX Products GmbH
 + *
 + * 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 dt-bindings/gpio/gpio.h
 +#include dt-bindings/interrupt-controller/irq.h
 +#include dt-bindings/input/input.h
 +#include exynos5250.dtsi
 +
 +/ {
 +   model = Google Spring;
 +   compatible = google,spring, samsung,exynos5250, samsung,exynos5;
 +
 +   memory {
 +   reg = 0x4000 0x8000;
 +   };
 +
 +   chosen {
 +   bootargs = console=tty1;
 +   };
 +
 +   gpio-keys {
 +   compatible = gpio-keys;
 +   pinctrl-names = default;
 +   pinctrl-0 = power_key_irq, lid_irq;
 +
 +   power {
 +   label = Power;
 +   gpios = gpx1 3 GPIO_ACTIVE_LOW;
 +   linux,code = KEY_POWER;
 +   gpio-key,wakeup;
 +   };
 +
 +   lid-switch {
 +   label = Lid;
 +   gpios = gpx3 5 GPIO_ACTIVE_LOW;
 +   linux,input-type = 5; /* EV_SW */
 +   linux,code = 0; /* SW_LID */
 +   debounce-interval = 1;
 +   gpio-key,wakeup;
 +   };
 +   };
 +
 +   usb-hub {
 +   compatible = smsc,usb3503a;
 +   reset-gpios = gpe1 0 GPIO_ACTIVE_LOW;
 +   };

Last I remember

Re: [PATCH v6 00/10] ARM: dts: exynos: Prepare Spring

[Doug Anderson]

Andreas,

On Sat, Aug 2, 2014 at 3:25 AM, Andreas Färber afaer...@suse.de wrote:
 Hi,

 Am 02.08.2014 06:57, schrieb Doug Anderson:
 On Fri, Aug 1, 2014 at 7:34 PM, Javier Martinez Canillas
 javier.marti...@collabora.co.uk wrote:
 On 08/02/2014 02:52 AM, Andreas Färber wrote:

 Based on the preinstalled 3.8 based ChromeOS kernel and previous 3.15
 based attempts by Stephan and me that broke for 3.16, I've prepared a
 device tree for the HP Chromebook 11 aka Google Spring.

 v6 renames a node and reverts dp_hpd.

 Not yet enabled are trackpad, Wifi and sound.

 I made a comment on patch 05/10 but the rest of the series looks good to 
 me. So
 for the remaining patches:

 Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

 NOTE: I thought that Tomasz Figa gave you his Reviewed-by on v5 for the 
 whole
 series as well but I didn't see his tag on the v6 patches.

 Yes, I thought that too.  I assume he's OK with the small changes you
 made between v5 and v6.  In the very least his Reviewed-by could be
 present on the patches that didn't change between the last two revs.

 I did add it to the bootargs, GPIO, USB3503 patches. All other patches
 were either split off or slightly changed due to dp_hpd[_gpio], so I
 didn't carry it over.

 Given Javier's review and Tomasz's review and Vincent's comments, I'll
 probably skip all the work of reviewing the rest of the series unless
 someone really wants me to.  ;)

 Could you maybe give an Rb or Ab for the actual Spring patch to have the
 Cc: updated? :)

Done.


 Note that if there's some problem that can't be resolved by selectively
 dropping patches, I won't be available next week, so you'll either have
 to provide fixups for Kukjin to squash or wait till I've returned.

 One thing I've wondered is whether we should put status = disabled on
 the dp node with some comment, since it's known not to work as is (but
 better having the data here than leaving it out, I believe).

Don't know about this one.


 Of course if either of you has input on the discussions on the drm
 bridge/panel series V6 [1] for how to enable non-simplefb display and
 iommus, that would be valuable.

I've been letting the graphics folks and Samsung hash out the graphics
patches, so I don't think I'll be much help here.


 [1] http://www.spinics.net/lists/linux-samsung-soc/msg35274.html


 And when one thing is accomplished, I am always quick to look forward:

 I've taken a quick look at sound nodes: According to 3.8 DT, Spring uses
 max98089 whereas Snow has 98091, so different codec driver and still
 lacking DT binding support. I might look into trivially enabling
 sound/soc/codecs/max98089.c through a maxim,max98089 OF match table
 once this series lands in linux-next. As for the driver, can we reuse
 http://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/tree/sound/soc/samsung/snow.c?h=for-next
 with a google,spring-audio-max98089, or are code changes needed?

I don't know this offhand.


 Both of you mentioned limitations of cros_ec i2c passthrough leading to
 a forked tps65090 driver downstream - I don't think I can be of help
 there, as I guess simply copying a driver will not be an option. ;)
 https://code.google.com/p/chromium/issues/detail?id=391797

Yup, I think this will be real work for someone.  I made a quick
attempt and failed at it and I haven't had time to work on it since
(and don't necessarily expect to have time in the near future)...  I
think it is possible for anyone versed in i2c to figure this out based
on what I already posted and what's in our local tree...


 For the touchpad it seems DT support has landed in the input tree as
 atmel,maxtouch. Backporting just that patch does not make it work
 though. (Tried the rejected pinctrl approach to be on the safe side.)
 https://code.google.com/p/chromium/issues/detail?id=371114
 https://patchwork.kernel.org/patch/3976801/

This is the same work as needed for pit and pi, I believe.  Perhaps
Javier or Dmitry has this on their todo list?


 I thought the internal xhci would have the webcam on it, but I don't see
 it in lsusb. Does that need some pinctrl or tps65090 regulator? Once
 appearing on a bus, which driver config option will it need?

Perhaps tps65090 FET5?  That looks like what the device tree says in
our local tree.

-Doug
--
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 v5 01/10] ARM: dts: Fix MMC pinctrl for exynos5250-snow

[Doug Anderson]

Hi,

On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber afaer...@suse.de wrote:
 The pinctrl properties should be on the device directly and not on the
 slot sub-node.

 Reported-by: Doug Anderson diand...@chromium.org
 Cc: Jaehoon Chung jh80.ch...@samsung.com
 Reviewed-by: Tomasz Figa t.f...@samsung.com
 Signed-off-by: Andreas Färber afaer...@suse.de

Let's land this one before Jaehoon's, since it was a hidden
functionality change in his patch.  It will be an easy conflict to
resolve when his patch is applied.

Reviewed-by: Doug Anderson diand...@chromium.org
--
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 v5 02/10] ARM: dts: Fold exynos5250-cros-common into exynos5250-snow

[Doug Anderson]

Andreas,

On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber afaer...@suse.de wrote:
 exynos5250-cros-common.dtsi was meant for sharing common pieces across
 ChromeOS devices. This turned out premature, as several devices ended up
 in the common file that are not common after all. Since the remaining
 common ChromeOS pieces are fairly minor,  exynos5250-cros-common.dtsi
 was requested to be merged into the Snow device tree, sharing only the
 keyboard controller for now. This may be re-evaluated as both mature.

 Suggested-by: Doug Anderson diand...@chromium.org
 Reviewed-by: Tomasz Figa t.f...@samsung.com
 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  v4 - v5:
  * Extended commit message (Tomasz Figa)

  v3 - v4: Unchanged

  v2 - v3:
  * Renamed subject to match Kukjin's style
  * Rebased onto MMC pinctrl bug fix (Doug Anderson)

  v2: New (Doug Anderson)

  arch/arm/boot/dts/exynos5250-cros-common.dtsi | 164 
 --
  arch/arm/boot/dts/exynos5250-snow.dts | 164 
 +++---
  2 files changed, 145 insertions(+), 183 deletions(-)

Reviewed-by: Doug Anderson diand...@chromium.org

I'd suggest that this land sooner rather than later to avoid future conflicts.
--
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 v5 03/10] ARM: dts: Clean up exynos5250-snow

[Doug Anderson]

Andreas,

On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber afaer...@suse.de wrote:
 Use the new style of referencing inherited nodes and use symbolic names.
 Reorder one pinctrl node in GPIO order.

 Goal is the alignment of all exynos5250 based device trees for comparison.

 Suggested-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  v4 - v5:
  * Introduced labels to consistently use new referencing style (Tomasz)
  * Use IRQ_TYPE_* constants
  * Use some more GPIO_ACTIVE_*

  v3 - v4: Unchanged

  v3: New (Doug Anderson)

  arch/arm/boot/dts/exynos5250-snow.dts | 291 
 +-
  arch/arm/boot/dts/exynos5250.dtsi |  20 +--

As much as possible it's nice to touch the main exynos dtsi file and
specific board files in different patches.  Among other things it
makes backporting the patch and resolving merge conflicts easier (if
someone doesn't care about snow they could just pick up the main dtsi,
for instance).

I'm not a total stickler and I'd love to see this land quickly to
avoid conflicts, though...


 +sd3_clk {
 +   samsung,pin-drv = 0;
 +};
 +
 +sd3_cmd {
 +   samsung,pin-pud = 3;
 +   samsung,pin-drv = 0;
 +};
 +
 +sd3_bus4 {

Itty bitty bitty nit that bus sorts alphabetically above clk.  ;)
Maybe Kukjin would be willing to sort these when he applies?


Thank you for all your hard work on this one.  Things look MUCH MUCH
nicer!  I did a pretty thorough review of your changes and it all
looks good.

Reviewed-by: Doug Anderson diand...@chromium.org
--
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 v5 04/10] ARM: dts: Fill in bootargs for exynos5250-snow

[Doug Anderson]

Hi,

On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber afaer...@suse.de wrote:
 exynos5250-cros-common.dtsi had an empty /chosen node.
 Fill in exemplary boot arguments.

 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  v5: New
  Cleanup for /chosen node moved into -snow.dts.

  arch/arm/boot/dts/exynos5250-snow.dts | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
 b/arch/arm/boot/dts/exynos5250-snow.dts
 index 7680d5e03fb3..c4b0c73c736d 100644
 --- a/arch/arm/boot/dts/exynos5250-snow.dts
 +++ b/arch/arm/boot/dts/exynos5250-snow.dts
 @@ -27,6 +27,7 @@
 };

 chosen {
 +   bootargs = console=tty1;

As mentioned earlier, I don't think this is a particularly useful
change.  Just this boot argument is not enough to boot with anyway, so
listing it doesn't really help anyone.  In theory you could make some
assertion about what the most popular boot device and filesystem is,
but it seems unlikely to cover the majority of the cases.

I won't NAK this change myself, but I certainly won't push for it.

-Doug
--
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