Chris,
On Thu, Jun 27, 2013 at 9:44 AM, Chris Ball c...@laptop.org wrote:
This hunk breaks the build for me, because err_setup_bus and ret are
used in the error path of the call to mmc_add_host() in this function.
I'll push a version that leaves those in. Let me know if you think
something
Jaehoon,
On Mon, Jun 17, 2013 at 9:51 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Doug,
I have one question for using clock-frequency.
I found the fixed-rate-clocks feature.
If we want to set clock-frequency, then can we use the fixed-rate-clocks?
i'm not sure how use the
Tomasz / Mark,
On Fri, Jun 7, 2013 at 3:30 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
On Friday 07 of June 2013 11:24:04 Mark Brown wrote:
On Fri, Jun 07, 2013 at 12:19:58PM +0200, Tomasz Figa wrote:
This interesting case makes me think that regulator core should
differentiate between
As of now we rely on code outside of the driver to set the ciu clock
frequency. There's no reason to do that. Add support for setting up
the clock in the driver during probe.
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Jaehoon Chung jh80.ch...@samsung.com
---
Changes in v2
Tomasz,
On Fri, Jun 7, 2013 at 10:42 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
A question just out of curiousity: Is it really correct to have one vmmc
regulator for the whole device, instead of one regulator per slot?
This might be something obvious, but I don't know any details about
.
Fix this limitation by adding the ability to make vmmc required. If a
vmmc-supply is specified in the device tree we'll assume that vmmc is
required.
Signed-off-by: Doug Anderson diand...@chromium.org
---
.../devicetree/bindings/mmc/synopsis-dw-mshc.txt | 3 +++
drivers/mmc/host/dw_mmc.c
Padma,
On Mon, Jun 3, 2013 at 9:25 PM, Padma Venkat padma@gmail.com wrote:
Hi Doug,
On Tue, Jun 4, 2013 at 1:43 AM, Doug Anderson diand...@chromium.org wrote:
Padmavathi,
On Sun, Jun 2, 2013 at 10:19 PM, Padmavathi Venna padm...@samsung.com
wrote:
Audio subsystem introduced
/clk-exynos-audss.c | 133
include/dt-bindings/clk/exynos-audss-clk.h | 25
4 files changed, 223 insertions(+), 0 deletions(-)
Thanks for fixing up my nits. This looks good to me.
Reviewed-by: Doug Anderson diand...@chromium.org
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
Responded on patch set 4 already, but this is the same. I'm happy with this.
Reviewed-by: Doug Anderson diand...@chromium.org
/exynos5250.dtsi | 10 ++
Would still like to see a separate patch documenting these clocks in
Documentation/devicetree/bindings/sound/samsung-i2s.txt. ...but
what's here looks good, thanks!
Reviewed-by: Doug Anderson diand...@chromium.org
Padmavathi,
On Sun, Jun 2, 2013 at 10:19 PM, Padmavathi Venna padm...@samsung.com wrote:
+static unsigned long reg_save[][2] = {
+ {ASS_CLK_SRC, 0},
+ {ASS_CLK_DIV, 0},
+ {ASS_CLK_GATE, 0},
+};
+
+/* list of all parent clock list */
+static const char *mout_audss_p[]
Padmavathi,
On Sun, Jun 2, 2013 at 10:19 PM, Padmavathi Venna padm...@samsung.com wrote:
Audio subsystem introduced in s5pv210 and exynos platforms
which has a internal clock controller. This patch adds a node
for the same on exynos5250.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Padmavathi,
On Sun, Jun 2, 2013 at 10:19 PM, Padmavathi Venna padm...@samsung.com wrote:
+ clocks = clock_audss EXYNOS_I2S_BUS,
+ clock_audss EXYNOS_I2S_BUS,
+ clock_audss EXYNOS_SCLK_I2S,
+ clock_audss
Andrew,
On Mon, Jun 3, 2013 at 4:46 PM, Andrew Bresticker abres...@chromium.org wrote:
I think this is supposed to be xxti which might or might not be
fin_pll. In the exynos4 code these are two different clocks that
are chosen by OM[0]. I'd bet that 99% of the time they are the same,
but it
Wolfram / Guenter / Stephen,
Thanks for your reviews. New version on its way...
On Tue, Apr 16, 2013 at 2:36 AM, Wolfram Sang w...@the-dreams.de wrote:
uses GPIO lines and a challange response mechanism or something like
that. There might be other GPIO based arbitrations in the future
on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree. The current incarnation as a
mux driver is as suggested by Grant Likely. See
https://patchwork.kernel.org/patch/1877311/ for some history.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon
Guenter,
On Tue, Apr 16, 2013 at 9:45 AM, Guenter Roeck li...@roeck-us.net wrote:
On Tue, Apr 16, 2013 at 09:29:00AM -0700, Doug Anderson wrote:
The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
where masters need to claim the bus with a GPIO before they can start
From: Thomas Abraham thomas.abra...@linaro.org
With device core now able to setup the default pin configuration,
the pin configuration code based on the deprecated Samsung specific
gpio bindings is removed.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Signed-off-by: Doug Anderson
Wolfram,
Thanks for your review!
On Mon, Apr 8, 2013 at 3:26 AM, Wolfram Sang w...@the-dreams.de wrote:
I'd like to have the bindings more generic. They should allow for n
possible masters IMO. It doesn't need to be implemented right now, but
it should be possible to add that later.
Done.
on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree. The current incarnation as a
mux driver is as suggested by Grant Likely. See
https://patchwork.kernel.org/patch/1877311/ for some history.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon
on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree. The current incarnation as a
mux driver is as suggested by Grant Likely. See
https://patchwork.kernel.org/patch/1877311/ for some history.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon
Wolfram,
On Fri, Mar 29, 2013 at 4:58 AM, Wolfram Sang w...@the-dreams.de wrote:
I can't recall the reason standard I2C bus arbitration is not working
and why this is needed. I need the feeling this is a solution and not a
workaround. I mean driver bugs can be fixed and I am unsure if it is a
Naveen,
On Wed, Mar 27, 2013 at 11:37 AM, Naveen Krishna Ch
naveenkrishna...@gmail.com wrote:
On 13 March 2013 13:40, Doug Anderson diand...@chromium.org wrote:
Without this change the exynos adc controller needed to have its phy
enabled in some out-of-driver C code. Add support
Hi,
On Wed, Mar 27, 2013 at 11:40 AM, Lars-Peter Clausen l...@metafoo.de wrote:
On 03/27/2013 07:35 PM, Naveen Krishna Ch wrote:
On 13 March 2013 13:39, Doug Anderson diand...@chromium.org wrote:
The exynos ADC won't work without a regulator called vdd and a clock
called adc. Document
Wolfram,
On Wed, Mar 13, 2013 at 9:36 AM, Doug Anderson diand...@chromium.org wrote:
The i2c-arbitrator-cros-ec driver implements the arbitration scheme
that the Embedded Controller (EC) on the ARM Chromebook expects to use
for bus multimastering. This i2c-arbitrator-cros-ec driver could also
The exynox4210-ehci and exynos4210-ohci nodes need a clock specified
using the common clock framework. Document it.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Documentation/devicetree/bindings/usb/exynos-usb.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git
The exynox4210-ehci and exynos4210-ohci nodes need a clock specified
using the common clock framework. Document it.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v2:
- Fixed embarrassing typo adc=usb. Thanks Jingoo!
Documentation/devicetree/bindings/usb/exynos-usb.txt | 10
-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Stephen Warren swar...@nvidia.com
Tested-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
Changes in v4: None
Changes in v3
Stephen,
On Wed, Mar 13, 2013 at 9:53 AM, Stephen Warren swar...@wwwdotorg.org wrote:
Changes in v4: None
Isn't this 'PATCH V3 REPOST' then?
In this case part 2 in the patch series changes but not parts 1 and 3.
I could have just reposted part 2 with a higher version, but that
makes it a
exynos adc driver under iio framwork
298489f iio:common: Use spi_sync_transfer() in STMicroelectronics ...
1d9a4cb IIO ADC support for AD7923
9a282b0 iio: Add OF support
3d277fc3 staging:iio: Remove adt7410 driver
Changes in v2:
- Match 'uV' - 'uv' change in Naveen's bindings.
Doug Anderson (4
The exynos ADC won't work without a regulator called vdd and a clock
called adc. Document this fact in the device tree bindings.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v2: None
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt | 8
1 file changed
/class/hwmon/hwmon1/device/temp1_input:38393
/sys/class/hwmon/hwmon2/device/temp1_input:37148
/sys/class/hwmon/hwmon3/device/temp1_input:38059
Tested-by: Doug Anderson diand...@chromium.org
___
devicetree-discuss mailing list
devicetree-discuss
Without this change the exynos adc controller needed to have its phy
enabled in some out-of-driver C code. Add support for specifying the
phy enable register by listing it in the reg list.
Signed-off-by: Doug Anderson diand...@chromium.org
---
.../devicetree/bindings/arm/samsung/exynos-adc.txt
Naveen's recent ADC cleanup and NTC thermistor patch.
Doug Anderson (4):
iio: adc: Document the regulator/clocks for exynos-adc
iio: adc: Add dt support for turning on the phy in exynos-adc
ARM: dts: Add adc to exynos5250 device tree file
ARM: dts: Add adc and thermistors for exynos5250-snow
The exynos ADC won't work without a regulator called vdd and a clock
called adc. Document this fact in the device tree bindings.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt | 8
1 file changed, 8 insertions
Hi,
On Tue, Mar 12, 2013 at 6:45 AM, Guenter Roeck li...@roeck-us.net wrote:
On Tue, Mar 12, 2013 at 02:09:26PM +0530, Naveen Krishna Chatradhi wrote:
This patch adds DT support to NTC driver to parse the
platform data.
Also adds the support to work as an iio device.
During the probe ntc
Wolfram,
On Fri, Feb 15, 2013 at 11:46 AM, Doug Anderson diand...@chromium.org wrote:
The i2c-arbitrator-cros-ec driver implements the arbitration scheme
that the Embedded Controller (EC) on the ARM Chromebook expects to use
for bus multimastering. This i2c-arbitrator-cros-ec driver could
configuration
2225141 New [1/2] ARM: dts: add pin state information in
client nodes for Exynos4 platforms
2225151 New [2/2] ARM: dts: add pin state information in
client nodes for Exynos5 platforms
Tested-by: Doug Anderson diand...@chromium.org
This patch looks good to me
Naveen,
On Sun, Mar 10, 2013 at 7:09 PM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
@@ -317,7 +346,7 @@ static int ntc_thermistor_get_ohm(struct ntc_data *data)
return data-pdata-read_ohm(data-pdev);
if (data-pdata-read_uV) {
- read_uV =
Stephen,
New version will come shortly with fixes below...
On Fri, Feb 15, 2013 at 8:39 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/14/2013 05:21 PM, Doug Anderson wrote:
The i2c-arbitrator-cros-ec driver implements the arbitration scheme
that the Embedded Controller (EC
On Fri, Feb 15, 2013 at 9:44 AM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Fri, Feb 15, 2013 at 10:38:29AM -0700, Stephen Warren wrote:
Either way though, I believe that upstream, no driver should be relying
on specific initcall levels in order to get dependencies/initialization
-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
Changes in v3:
- Handle of_find_i2c_adapter_by_node() failure more properly by
changing init order.
- Don't warn on -EPROBE_DEFER from calls
Mark / Stephen,
On Fri, Feb 15, 2013 at 2:24 AM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
You shouldn't have dummy regulators enabled at all, that'll break a
bunch of stuff including dependency resolution. They're a crutch to
help get things booting not something you should be
On Wed, Feb 13, 2013 at 4:54 PM, Doug Anderson diand...@chromium.org wrote:
You should be able to replace all that with:
module_platform_driver(i2c_arbitrator_driver);
Sigh. Yeah, I had that. ...but it ends up getting initted
significantly later in the init process and that was uncovering
Stephen,
On Thu, Feb 14, 2013 at 3:35 PM, Stephen Warren swar...@wwwdotorg.org wrote:
[1.51] platform-lcd supply lcd_vdd not found, using dummy regulator
What prints that? I assume that's some error-handling logic in the
platform-lcd driver. It's probably not detecting an
-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
Changes in v2:
- Renamed to i2c-arbitrator-cros-ec.
- Documented microsecond properties as optional; removed
bus-arbitration prefix since
Stephen,
On Thu, Feb 14, 2013 at 4:16 PM, Stephen Warren swar...@wwwdotorg.org wrote:
We can avoid that logic with has_full_constraints. That will be some
work to get done but also should be done at some point in time. Once
we use has_full_constraints we'll get ERR_PTR(-EPROBE_DEFER);
That
(i2c_arbitrator_init);
+
+static void __exit i2c_arbitrator_exit(void)
+{
+ platform_driver_unregister(i2c_arbitrator_driver);
+}
+module_exit(i2c_arbitrator_exit);
+
+MODULE_DESCRIPTION(GPIO-based I2C arbitrator driver);
+MODULE_AUTHOR(Doug Anderson diand...@chromium.org);
+MODULE_LICENSE(GPL);
+MODULE_ALIAS
Stephen,
Thank you for the review. Comments below (including changes I have
done locally). I probably won't have time to test / repost until
tomorrow.
On Wed, Feb 13, 2013 at 1:02 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/13/2013 11:02 AM, Doug Anderson wrote:
The i2c-arbitrator
Stephen,
On Wed, Feb 13, 2013 at 4:41 PM, Stephen Warren swar...@wwwdotorg.org wrote:
OK, going to go with i2c-arbitrator-cros-ec. Hopefully that sounds OK.
That seems fine. The mechanism seems potentially a little more generic
than just for cros-ec though, but I guess there's no harm naming
Vivek,
Sorry for being so absent from these reviews. I'll try to look over a
few patches today, but please don't hold up anything on account of my
reviews. I'm definitely a bit of an interested bystander in USB land.
;)
In general things look pretty good here. :) One last comment below...
Vivek,
On Mon, Jan 14, 2013 at 12:06 AM, Vivek Gautam
gautamvivek1...@gmail.com wrote:
Is it fine if we don't use macro for SHIFT, earlier code also doesn't use it.
Can we just do like this ..
#define HOST_CTRL0_FSEL_MASK (0x7 16)
#define HOST_CTRL0_FSEL_CLKSEL_50M
disable-wp
because the lack of a wp-gpios property means to use the special
purpose write protect line. On some other mmc devices the lack of
wp-gpios means that write protect should be disabled.
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Seungwon Jeon tgih@samsung.com
Vivek,
On Fri, Jan 11, 2013 at 4:40 AM, Vivek Gautam gautamvivek1...@gmail.com wrote:
+#define HOST_CTRL0_REFCLKSEL_MASK (0x3)
+#define HOST_CTRL0_REFCLKSEL_XTAL (0x0 19)
+#define HOST_CTRL0_REFCLKSEL_EXTL (0x1 19)
+#define HOST_CTRL0_REFCLKSEL_CLKCORE
disable-wp
because the lack of a wp-gpios property means to use the special
purpose write protect line. On some other mmc devices the lack of
wp-gpios means that write protect should be disabled.
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Seungwon Jeon tgih@samsung.com
Olof,
Thanks for your comments.
On Thu, Jan 10, 2013 at 3:01 PM, Olof Johansson o...@lixom.net wrote:
The previous code used the controller-common quirk field to set a
per-controller DW_MCI_QUIRK_NO_WRITE_PROTECT. Is there really need to
do this per-slot? And if so, please explain in the
Hi,
A followup as I did more investigation here...
On Thu, Jan 10, 2013 at 3:23 PM, Doug Anderson diand...@chromium.org wrote:
Olof,
Thanks for your comments.
On Thu, Jan 10, 2013 at 3:01 PM, Olof Johansson o...@lixom.net wrote:
The previous code used the controller-common quirk field
Vivek,
Nothing really serious below and things look good to me, but figured
I'd put a few nits in (sorry!).
On Fri, Dec 21, 2012 at 12:16 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
grant.lik...@secretlab.ca
Any more thought about this patch-set?
Or does this change seems fine?
These two changes look good to me. For both of them:
Reviewed-by: Doug Anderson diand...@chromium.org
___
devicetree-discuss mailing list
devicetree-discuss
Vivek,
On Fri, Dec 21, 2012 at 12:16 AM, Vivek Gautam
gautamvivek1...@gmail.com wrote:
Hi all,
On Wed, Dec 19, 2012 at 7:20 PM, Vivek Gautam gautamvivek1...@gmail.com
wrote:
CC: Doug Anderson
On Sat, Dec 15, 2012 at 12:53 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
On Thu, 13
Vivek,
On Wed, Dec 19, 2012 at 9:51 PM, Vivek Gautam gautamvivek1...@gmail.com wrote:
Hi Doug,
On Thu, Dec 20, 2012 at 3:18 AM, Doug Anderson diand...@chromium.org wrote:
Vivek,
Since you're changing the name, I would have expected to see a removal
of the old enum type in this patch. I
On Wed, Dec 19, 2012 at 10:37 PM, Vivek Gautam
gautamvivek1...@gmail.com wrote:
On Thu, Dec 20, 2012 at 5:00 AM, Doug Anderson diand...@chromium.org wrote:
On Tue, Dec 18, 2012 at 6:43 AM, Vivek Gautam gautam.vi...@samsung.com
wrote:
+static void s5p_ehci_phy_enable(struct s5p_ehci_hcd
Vivek,
On Tue, Dec 18, 2012 at 6:43 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
Updating the names of usb-phy types to more generic names:
USB_PHY_TYPE_DEIVCE USB_PHY_TYPE_HOST; and further update
its dependencies.
Since you're changing the name, I would have expected to see a removal
Vivek,
I don't really have a good 1 foot view about how all of the USB
bits fit together, but a few detail-oriented comments below.
On Tue, Dec 18, 2012 at 6:43 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
This patch adds host phy support to samsung-usbphy.c and
further adds support
Vivek,
Again, not a high-level review, but...
On Tue, Dec 18, 2012 at 6:43 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
Adding the phy driver to ehci-s5p. Keeping the platform data
for continuing the smooth operation for boards which still uses it
Signed-off-by: Vivek Gautam
Chris,
On Fri, Nov 30, 2012 at 3:57 AM, Seungwon Jeon tgih@samsung.com wrote:
Doug, Thanks to work.
Looks good to me with other patches.
Acked-by: Seungwon Jeon tgih@samsung.com
Does this series look reasonable to you? I can check back later when
things are less hectic, but I wanted
disable-wp
because the lack of a wp-gpios property means to use the special
purpose write protect line. On some other mmc devices the lack of
wp-gpios means that write protect should be disabled.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v3:
- New for this version
unchanged
- CMDLINE_FROM_BOOTLOADER=true, dt bootargs=empty, @data is empty string
CONFIG_CMDLINE (or if that's not defined)
Signed-off-by: Doug Anderson diand...@chromium.org
CC: devicetree-discuss@lists.ozlabs.org
CC: Grant Likely grant.lik...@secretlab.ca
CC: Benjamin Herrenschmidt b
unchanged
- CMDLINE_FROM_BOOTLOADER=true, dt bootargs=empty, @data is empty string
CONFIG_CMDLINE (or if that's not defined)
Signed-off-by: Doug Anderson diand...@chromium.org
CC: devicetree-discuss@lists.ozlabs.org
CC: Grant Likely grant.lik...@secretlab.ca
CC: Benjamin Herrenschmidt b
Ben,
Thank you for the review! See below for a question...
On Tue, Jan 10, 2012 at 9:03 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
The new logic is now documented in of_fdt.h and is copied here for
reference:
- CONFIG_CMDLINE_FORCE=true
CONFIG_CMDLINE
-
- CMDLINE_FROM_BOOTLOADER=true, dt bootargs=empty, @data is empty string
CONFIG_CMDLINE (or if that's not defined)
Signed-off-by: Doug Anderson diand...@chromium.org
CC: devicetree-disc...@lists-ozlabs.org
CC: Grant Likely grant.lik...@secretlab.ca
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers
71 matches
Mail list logo
