Re: [PATCH 2/2] Input: atmel_mxt_ts - Add keycodes array example

in the atmel support patch for Peach boards. The below patch improves the documentation for the gpio-property. That patch makes sense, and is a nice description, Acked-by: Stephen Warren diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt Example: touch@4b {

Re: [PATCH 6/6] ARM: dts: Add tps65090 FETs constraints

On 08/12/2014 10:44 AM, Javier Martinez Canillas wrote: The tps65090 PMU data manual [0] has a table that list the "Recommended operating conditions" for each regulator. Add the information about the FET constraints to its dtsi file. [0]: http://www.ti.com/lit/ds/symlink/tps65090.pdf I'm worri

Re: [PATCH 1/6] ARM: dts: Create fragment for tps65090 PMU

On 08/12/2014 10:44 AM, Javier Martinez Canillas wrote: The tps65090 is a Power Management Unit (PMU) used in several boards so the same information is described on different DTS. It is better to create a .dtsi fragment that can be included. To be honest, I'm not sure that this file is useful.

Re: [PATCH] ARM: convert all "mov.* pc, reg" to "bx reg" for ARMv6+ (part1)

iecemeal, and miss some instances, change all > the "mov pc" instances to use the new macro, with the exception of > the "movs" instruction and the kprobes code. This allows us to detect > the "mov pc, lr" case and fix it up - and also gives us the possibilit

Re: [PATCH] ARM: dts: Add mask-tpm-reset to the device tree

On 06/27/2014 12:30 PM, Doug Anderson wrote: > Stephen, > > On Fri, Jun 27, 2014 at 11:20 AM, Stephen Warren > wrote: >> On 06/27/2014 10:45 AM, Doug Anderson wrote: >>> Stephen, >>> >>> On Fri, Jun 27, 2014 at 9:10 AM, Stephen Warren >>&

Re: [PATCH] ARM: dts: Add mask-tpm-reset to the device tree

On 06/27/2014 10:45 AM, Doug Anderson wrote: > Stephen, > > On Fri, Jun 27, 2014 at 9:10 AM, Stephen Warren wrote: >> Surely there's a driver (or could be a driver) for the TPM chip, and >> that driver should have a reset-mask-gpios property, so the driver

Re: [PATCH] ARM: dts: Add mask-tpm-reset to the device tree

On 06/27/2014 06:17 AM, Tomasz Figa wrote: > Hi Doug, > > On 26.06.2014 17:25, Doug Anderson wrote: >> Tomasz, >> >> On Thu, Jun 26, 2014 at 2:52 AM, Tomasz Figa wrote: >>> Hi Vikas, Doug, >>> >>> On 26.06.2014 11:15, Vikas Sajjan wrote: From: Doug Anderson The mask-tpm-reset GPIO

Re: [PATCH v3 5/7] mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources

On 06/17/2014 02:53 AM, Paul Bolle wrote: > Doug, > > On Fri, 2014-06-13 at 08:22 -0700, Doug Anderson wrote: >> On Fri, Jun 13, 2014 at 1:08 AM, Paul Bolle wrote: >>> On Wed, 2014-06-11 at 08:11 -0700, Doug Anderson wrote: This is a config option on the ChromeOS EC

Re: [PATCH v3 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2

On 04/30/2014 11:44 AM, Doug Anderson wrote: > This adds the EC i2c tunnel (and devices under it) to the > tegra124-venice2 device tree. I've applied this to Tegra's for-3.17/dt branch. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majo

[PATCH] ASoC: free jack GPIOs before the sound card is freed

From: Stephen Warren This is the same change as commit fb6b8e71448a "ASoC: tegra: free jack GPIOs before the sound card is freed", but applied to all other ASoC machine drivers where code inspection indicates the same problem exists. That commit's

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

On 05/23/2014 02:36 PM, Thierry Reding wrote: > From: Thierry Reding > > This commit introduces a generic device tree binding for IOMMU devices. > Only a very minimal subset is described here, but it is enough to cover > the requirements of both the Exynos System MMU and Tegra SMMU as > discussed

Re: [PATCH 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2

On 04/17/2014 11:59 AM, Doug Anderson wrote: > This adds the EC i2c tunnel (and devices under it) to the > tegra124-venice2 device tree. Did the MFD patches at the start of this series get applied yet? I was hoping to apply this one patch to the Tegra tree for 3.16, and that needs to happen by tom

Re: [PATCH v2 5/6] usb: host: ehci-tegra: Use devm_ioremap_resource instead of devm_ioremap

On 05/10/2014 06:00 AM, Vivek Gautam wrote: > Using devm_ioremap_resource() API should actually be preferred over > devm_ioremap(), since the former request the mem region first and then > gives back the ioremap'ed memory pointer. > devm_ioremap_resource() calls request_mem_region(), therby prevent

Re: [PATCH v3 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2

On 04/30/2014 11:44 AM, Doug Anderson wrote: > This adds the EC i2c tunnel (and devices under it) to the > tegra124-venice2 device tree. I'll happily take this into the Tegra tree once the patch containing the binding it uses is applied. -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH v3 6/7] i2c: ChromeOS EC tunnel driver

omebook 11 (and perhaps could even be used to access > tps65090 on the HP Chromebook 11 instead of using a special driver, > but I haven't researched that enough). The binding looks reasonable to me, so that part, Acked-by: Stephen Warren -- To unsubscribe from this list: send the line "

Re: [PATCH 51/97] ARM: l2c: remove platforms/SoCs setting early BRESP

On 04/28/2014 06:02 PM, Simon Horman wrote: > On Mon, Apr 28, 2014 at 08:30:32PM +0100, Russell King wrote: >> Since we now automatically enable early BRESP in core L2C-310 code when >> we detect a Cortex-A9, we don't need platforms/SoCs to set this bit >> explicitly. Instead, they should seek to

Re: [PATCH 49/97] ARM: l2c: fix register naming

ll auxiliary control register definitions. Acked-by: Stephen Warren -- 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 51/97] ARM: l2c: remove platforms/SoCs setting early BRESP

control register. Acked-by: Stephen Warren -- 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 00/16] Another 16 L2C patches

On 04/28/2014 11:12 AM, Stephen Warren wrote: > On 04/28/2014 10:56 AM, Russell King - ARM Linux wrote: >> So, in response to Matt Porter's complaint about breaking prima2, here's >> another 16 patches which changes the way the L2 cache is initialised on >> man

Re: [PATCH v3 1/3] base: power: Add generic OF-based power domain look-up

On 04/23/2014 10:46 AM, Tomasz Figa wrote: > This patch introduces generic code to perform power domain look-up using > device tree and automatically bind devices to their power domains. > Generic device tree binding is introduced to specify power domains of > devices in their device tree nodes. >

Re: [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU

On 04/28/2014 05:18 AM, Thierry Reding wrote: > On Mon, Apr 28, 2014 at 12:56:03PM +0200, Arnd Bergmann wrote: ... >> A lot of drivers probably only support one >> master, so they can just set #iommu-cells=<0>, others might require >> IDs that do not fit into one cell. > > You mean "#iommu-cells =

Re: [PATCH v2 0/7] Add cros_ec changes for newer boards

On 04/23/2014 06:32 AM, Lee Jones wrote: > On Tue, 22 Apr 2014, Doug Anderson wrote: > >> This series adds the most critical cros_ec changes for newer boards >> using cros_ec. Specifically: >> * Fixes timing/locking issues with the previously upstreamed (but >> never used upstream) cros_ec_spi

Re: [PATCH 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2

On 04/21/2014 01:35 PM, Doug Anderson wrote: > Stephen, > > On Mon, Apr 21, 2014 at 11:18 AM, Stephen Warren > wrote: >> On 04/17/2014 11:59 AM, Doug Anderson wrote: >>> This adds the EC i2c tunnel (and devices under it) to the >>> tegra124-venice2 device t

Re: [PATCH 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2

On 04/17/2014 11:59 AM, Doug Anderson wrote: > This adds the EC i2c tunnel (and devices under it) to the > tegra124-venice2 device tree. The series, Tested-by: Stephen Warren I can apply this one patch once the other patches in the series are acked or applied (in order to make sure

Re: [RESEND PATCH 6/7] i2c: ChromeOS EC tunnel driver

On 04/17/2014 12:36 PM, Doug Anderson wrote: > On ARM Chromebooks we have a few devices that are accessed by both the > AP (the main "Application Processor") and the EC (the Embedded > Controller). These are: > * The battery (sbs-battery). > * The power management unit tps65090. ... > On the Samsu

Re: [PATCH 1/2] ARM: DT: fix gic interrupt controller documentation

On 03/13/2014 11:40 AM, Tim Harvey wrote: > When using interrupt-maps, the size of a map entry is #address-cells + > #interrupt-cells for the parent interrupt controller. For the ARM GIC > address-cells should be 0 as this is not used. > > This patch fixes the example by correctly specifying #ad

Re: [PATCH v2 1/6] ARM: dts: tegra: add PCIe interrupt mapping properties

On 03/05/2014 06:25 AM, Lucas Stach wrote: > Those are defined by the common PCI binding. I've applied this to Tegra's for-3.15/dt branch. -- 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 h

Re: [PATCH v2 2/6] PCI: tegra: use new OF interrupt mapping when possible

On 03/05/2014 06:25 AM, Lucas Stach wrote: > This is the recommended method of doing the IRQ > mapping. For old devicetrees we fall back to the > previous practice. Tested-by: Stephen Warren I tested both with and without patch 1/6, and the PCIe-based NIC on Beaver worked fine e

Re: [PATCH v2 1/6] ARM: dts: tegra: add PCIe interrupt mapping properties

On 03/05/2014 06:25 AM, Lucas Stach wrote: > Those are defined by the common PCI binding. It sounds like there's no dependency between pathces 1/6 and 2/6, so I should apply 1/6 to the Tegra tree, and Bjorn apply 2/6 to the PCI tree? -- To unsubscribe from this list: send the line "unsubscribe lin

Re: [PATCH 1/7] ARM: dts: tegra: add PCIe interrupt mapping properties

On 02/28/2014 10:28 AM, Lucas Stach wrote: > Those are defined by the common PCI binding. I have no reason to object to the two Tegra patches, but I'll wait for Thierry to take a closer look. I expect once he does, I would apply patch 1/7 through the Tegra tree, and Bjorn would take patch 2/7 thr

Re: [RFC PATCHv1] usb: dwc2: Combine the dwc2 and s3c_hsotg into a single USB DRD driver.

On 02/04/2014 02:45 PM, dingu...@altera.com wrote: > From: Dinh Nguyen > > This means that the driver can be in host or peripheral mode when the > appropriate > connector is used. When an A-cable is plugged in, the driver behaves in host > mode, and when a B-cable is used, the driver will be in

Re: [PATCH V2] regulator: fixed: update to devm_* API

On 01/27/2014 08:12 PM, Manish Badarkhe wrote: > Update the code to use devm_* API so that driver core will manage > resources. I'm not sure why this patch is sent to linux-te...@vger.kernel.org; it seems nothing to do with Tegra (or Samsung or OMAP for that matter). -- To unsubscribe from this li

Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.

On 12/03/2013 02:29 AM, Linus Walleij wrote: ... > So I guess what you're after is a kind of hog that will be pushed > aside and ignored if a struct device with an associated state appears > that will use the same pin? That probably would be useful. Perhaps we should just make all hogs not exclusi

Re: [PATCH V3 0/6] cpufreq: suspend early/resume late

On 11/25/2013 07:11 AM, Viresh Kumar wrote: > This patchset adds cpufreq callbacks to dpm_{suspend|resume}() for handling > suspend/resume of cpufreq governors and core. This is required for early > suspend > and late resume of governors and cpufreq core. Patches 1-3,6, Tested-by: St

Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.

On 11/19/2013 05:02 PM, Kyungmin Park wrote: > On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren wrote: >> On 11/19/2013 11:59 AM, Doug Anderson wrote: >>> On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren >>> wrote: >>>> On 11/19/2013 10:15 AM, Tomasz F

Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.

On 11/19/2013 11:59 AM, Doug Anderson wrote: > On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren > wrote: >> On 11/19/2013 10:15 AM, Tomasz Figa wrote: >>> This patch extends the range of settings configurable via pinfunc API >>> to cover pin value as well. This a

Re: [PATCH] pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes

n-pud = <4>; > samsung,pin-drv = <3>; > }; > }; OK, that all looks great! > diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt > b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt The DT changes

Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.

On 11/19/2013 10:15 AM, Tomasz Figa wrote: > This patch extends the range of settings configurable via pinfunc API > to cover pin value as well. This allows configuration of default values > of pins. Shouldn't there be a driver that acquires the GPIO that's output to the pin, and configures the ou

Re: [PATCH] ARM: move firmware_ops to drivers/firmware

On 11/18/2013 10:30 AM, Catalin Marinas wrote: > On Mon, Nov 18, 2013 at 05:03:37PM +0000, Stephen Warren wrote: >> On 11/18/2013 04:58 AM, Catalin Marinas wrote: >> ... >>> Of course, trusted foundations interface could be plugged into cpu_ops >>> on arm64 but I

Re: [PATCH] ARM: move firmware_ops to drivers/firmware

On 11/18/2013 10:10 AM, Russell King - ARM Linux wrote: > On Mon, Nov 18, 2013 at 10:03:37AM -0700, Stephen Warren wrote: >> On 11/18/2013 04:58 AM, Catalin Marinas wrote: >> ... >>> Of course, trusted foundations interface could be plugged into cpu_ops >>>

Re: [PATCH] ARM: move firmware_ops to drivers/firmware

On 11/18/2013 04:58 AM, Catalin Marinas wrote: ... > Of course, trusted foundations interface could be plugged into cpu_ops > on arm64 but I will NAK it on the grounds of not using the PSCI API, nor > the SMC calling convention (and it's easy to fix when porting to ARMv8). > If a supported standard

Re: [PATCH] ARM: move firmware_ops to drivers/firmware

On 11/17/2013 08:59 AM, Catalin Marinas wrote: > On 17 November 2013 08:49, Alexandre Courbot wrote: >> The ARM tree includes a firmware_ops interface that is designed to >> implement support for simple, TrustZone-based firmwares but could >> also cover other use-cases. It has been suggested that

Re: [PATCH 2/6] clk: exynos5410: register clocks using common clock framework

On 10/01/2013 10:17 AM, Vyacheslav Tyrtov wrote: > From: Tarek Dakhran > > The EXYNOS5410 clocks are statically listed and registered > using the Samsung specific common clock helper functions. > diff --git a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt > b/Documentation/devicet

Re: [PATCH 09/10] pwm-backlight: Use an optional power supply

On 10/01/2013 02:53 PM, Thierry Reding wrote: > On Tue, Oct 01, 2013 at 12:43:57PM -0600, Stephen Warren wrote: >> On 09/23/2013 03:41 PM, Thierry Reding wrote: >>> Many backlights require a power supply to work properly. This >>> commit uses a power-supply regulator

Re: [PATCH 05/10] ARM: SAMSUNG: Initialize PWM backlight enable_gpio field

On 10/01/2013 02:43 PM, Thierry Reding wrote: > On Tue, Oct 01, 2013 at 12:31:04PM -0600, Stephen Warren wrote: >> On 09/23/2013 03:41 PM, Thierry Reding wrote: >>> The GPIO API defines 0 as being a valid GPIO number, so this >>> field needs to be initialized explicitly.

Re: [PATCH 10/10] pwm-backlight: Allow backlight to remain disabled on boot

On 09/23/2013 03:41 PM, Thierry Reding wrote: > The default for backlight devices is to be enabled immediately when > registering with the backlight core. This can be useful for setups that > use a simple framebuffer device and where the backlight cannot otherwise > be hooked up to the panel. > >

Re: [PATCH 09/10] pwm-backlight: Use an optional power supply

On 09/23/2013 03:41 PM, Thierry Reding wrote: > Many backlights require a power supply to work properly. This commit > uses a power-supply regulator, if available, to power up and power down > the panel. I think that all backlights require a power supply, albeit the supply may not be SW-controllab

Re: [PATCH 08/10] pwm-backlight: Use new enable_gpio field

On 09/23/2013 03:41 PM, Thierry Reding wrote: > Make use of the new enable_gpio field and allow it to be set from DT as > well. Now that all legacy users of platform data have been converted to > initialize this field to an invalid value, it is safe to use the field > from the driver. > diff --git

Re: [PATCH 05/10] ARM: SAMSUNG: Initialize PWM backlight enable_gpio field

On 09/23/2013 03:41 PM, Thierry Reding wrote: > The GPIO API defines 0 as being a valid GPIO number, so this field needs > to be initialized explicitly. > static void __init smdkv210_map_io(void) > @@ -70,6 +70,7 @@ static struct samsung_bl_drvdata samsung_dfl_bl_data > __initdata = { >

Re: [PATCH 01/10] pwm-backlight: Refactor backlight power on/off

On 09/23/2013 03:40 PM, Thierry Reding wrote: > In preparation for adding an optional regulator and enable GPIO to the > driver, split the power on and power off sequences into separate > functions to reduce code duplication at the multiple call sites. > diff --git a/drivers/video/backlight/pwm_bl

Re: [PATCH 00/26] ARM: provide common arch init for DT clocks

On 09/18/2013 01:52 PM, Sebastian Hesselbarth wrote: > On 09/18/2013 09:47 PM, Jason Cooper wrote: >> On Wed, Sep 18, 2013 at 07:53:33PM +0200, Sebastian Hesselbarth wrote: >> ... >>> Sebastian Hesselbarth (26): >>>ARM: nomadik: move mtu setup to clocksource init ... >> >> How would you like to

Re: [PATCH v8 12/12] V4L: Add driver for s5k4e5 image sensor

On 09/13/2013 06:55 AM, Philipp Zabel wrote: > Hi Arun, > > Am Donnerstag, den 12.09.2013, 17:37 +0530 schrieb Arun Kumar K: >> This patch adds subdev driver for Samsung S5K4E5 raw image sensor. >> Like s5k6a3, it is also another fimc-is firmware controlled >> sensor. This minimal sensor driver do

Re: [PATCH 3/3] ARM: dts: Disable I2C controllers by default on Exynos5250

On 09/12/2013 06:58 AM, Tomasz Figa wrote: > Hi Mark, > > On Thursday 12 of September 2013 11:40:27 Mark Brown wrote: >> From: Mark Brown >> >> Ensure that unused I2C controllers are not activated, causing problems >> due to inappropriate pinmuxing or similar, by marking the controllers as >> dis

Re: [PATCH v8 1/7] irqchip: vic: Parse interrupt and resume masks from device tree

On 08/23/2013 05:04 PM, Tomasz Figa wrote: > On Friday 23 of August 2013 16:11:18 Stephen Warren wrote: >> On 08/22/2013 05:22 PM, Tomasz Figa wrote: >>> This patch extends vic_of_init to parse valid interrupt sources >>> and resume sources masks from device tree. >

Re: [PATCH] s5p-jpeg: Add initial device tree support for S5PV210/Exynos4210 SoCs

> and Exynos5 series and support for them will be added in subsequent patches. >> >> Cc: Andrzej Pietrasiewicz >> Signed-off-by: Sylwester Nawrocki > > Could a DT maintainer review/Ack the binding in this patch ? The binding looks reasonable to me, so, Acked-by: Stephen

Re: [PATCH v8 1/7] irqchip: vic: Parse interrupt and resume masks from device tree

On 08/22/2013 05:22 PM, Tomasz Figa wrote: > This patch extends vic_of_init to parse valid interrupt sources > and resume sources masks from device tree. > > If mask values are not specified in device tree, all sources > are assumed to be valid, as before this patch. Can you explain further why t

Re: [PATCH v7] s5k5baf: add camera sensor driver

; - S5K5BAF-ISP - Image Signal Processor, formats up to 1600x1200, > pre/post ISP cropping, downscaling via selection API, controls. The binding, Acked-by: Stephen Warren (although it would be great if another DT binding maintainer gave it a quick look-over to make sure I didn't miss anythin

Re: [PATCH 09/16] clk: samsung: pll: Use new registration method for PLL45xx

On 08/21/2013 07:17 AM, Yadwinder Singh Brar wrote: >> }; >> >> +static struct __initdata samsung_pll_clock exynos4210_plls[nr_plls] = { > > NIT: __initdata should be at last. It's helpful if you only quote as much of the patch as you need to in order to reply to it; it wasn't obvious in your me

Re: [PATCH v6] s5k5baf: add camera sensor driver

On 08/20/2013 10:03 AM, Andrzej Hajda wrote: > Driver for Samsung S5K5BAF UXGA 1/5" 2M CMOS Image Sensor > with embedded SoC ISP. > The driver exposes the sensor as two V4L2 subdevices: > - S5K5BAF-CIS - pure CMOS Image Sensor, fixed 1600x1200 format, > no controls. > - S5K5BAF-ISP - Image Signal

Re: [PATCH 1/8] Documentation: devicetree: Update Exynos MCT bindings description

On 08/20/2013 11:12 AM, Tomasz Figa wrote: > On Tuesday 20 of August 2013 11:00:53 Stephen Warren wrote: >> On 08/20/2013 07:52 AM, Tomasz Figa wrote: >>> This patch updates description of device tree bindings for Exynos MCT >>> >>> (multicore timers). Namely

Re: [PATCH 01/16] pwm: samsung: Update DT bindings documentation to cover clocks

ailable. It might be nice to explicitly enumerate which variants (or rather, I suppose which exact compatible values) support which optional clocks. However, I suppose it's fine to just say "go read the HW manual" instead. So, this patch, Acked-by: Stephen Warren (although this pa

Re: [PATCH 1/8] Documentation: devicetree: Update Exynos MCT bindings description

On 08/20/2013 07:52 AM, Tomasz Figa wrote: > This patch updates description of device tree bindings for Exynos MCT > (multicore timers). Namely: > - added note about simplified specification of local timer interrupts, >when using single per-processor interrupt for all local timers, > - change

Re: [PATCH RFC v5] s5k5baf: add camera sensor driver

On 08/19/2013 04:53 PM, Tomasz Figa wrote: > On Monday 19 of August 2013 16:30:45 Stephen Warren wrote: >> On 08/19/2013 11:25 AM, Sylwester Nawrocki wrote: >>> On 08/19/2013 03:25 PM, Pawel Moll wrote: >>>> On Mon, 2013-08-19 at 14:18 +0100, Andrzej Hajda wr

Re: [PATCH RFC v5] s5k5baf: add camera sensor driver

On 08/19/2013 11:25 AM, Sylwester Nawrocki wrote: > On 08/19/2013 03:25 PM, Pawel Moll wrote: >> On Mon, 2013-08-19 at 14:18 +0100, Andrzej Hajda wrote: >>> +++ b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt >>> @@ -0,0 +1,51 @@ >>> +Samsung S5K5BAF UXGA 1/5" 2M CMOS Image Sensor wit

Re: [PATCH V4 1/4] ASoC: Samsung: I2S: Add quirks as driver data in I2S

On 08/12/2013 05:46 PM, Mark Brown wrote: > On Mon, Aug 12, 2013 at 05:18:34PM -0600, Stephen Warren wrote: >> On 08/12/2013 05:13 PM, Mark Brown wrote: > >>>> (although I dare say that at least samsung,supports-rstclr >>>> should be modified to u

Re: [PATCH V4 1/4] ASoC: Samsung: I2S: Add quirks as driver data in I2S

On 08/12/2013 05:13 PM, Mark Brown wrote: > On Mon, Aug 12, 2013 at 04:57:53PM -0600, Stephen Warren wrote: >> On 08/12/2013 03:49 AM, Padmavathi Venna wrote: > >>> +- compatible : should be one of the following. + - >>> samsung,s3c6410-i2s: for 8/16/24bit stereo

Re: [PATCH V4 1/4] ASoC: Samsung: I2S: Add quirks as driver data in I2S

(CCing DT maintainers...) On 08/12/2013 03:49 AM, Padmavathi Venna wrote: > Samsung has different versions of I2S introduced in different > platforms. Each version has some new support added for multichannel, > secondary fifo, s/w reset control and internal mux for rclk src clk. > Each newly added

Re: [PATCHv2 5/5] ARM: dts: Add dt binding documentation for exynos rotator

On 08/09/2013 07:15 AM, Tomasz Figa wrote: > Hi Chanho, > > On Friday 09 of August 2013 16:40:53 Chanho Park wrote: >> This patch describes each nodes of rotator and specifies a example how to >> bind it. >> diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt >> +* Samsung Ima

Re: [PATCH 1/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code

On 08/08/2013 04:10 PM, Tomasz Figa wrote: > On Thursday 08 of August 2013 15:47:19 Stephen Warren wrote: >> On 08/08/2013 03:19 PM, Tomasz Figa wrote: >>> On Thursday 08 of August 2013 15:00:52 Stephen Warren wrote: >>>> On 08/05/2013 06:26 AM, Marek Szyprowski wrot

Re: [PATCH 1/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code

On 08/08/2013 03:19 PM, Tomasz Figa wrote: > Hi Stephen, > > On Thursday 08 of August 2013 15:00:52 Stephen Warren wrote: >> On 08/05/2013 06:26 AM, Marek Szyprowski wrote: >>> MFC driver use custom bindings for managing reserved memory. Those >>> bindings are

Re: [PATCH 1/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code

On 08/05/2013 06:26 AM, Marek Szyprowski wrote: > MFC driver use custom bindings for managing reserved memory. Those bindings > are not really specific to MFC device and no even well discussed. They can > be easily replaced with generic, platform independent code for handling > reserved and contigu

Re: [RFC v3 02/13] [media] exynos5-fimc-is: Add Exynos5 FIMC-IS device tree bindings documentation

On 08/05/2013 04:37 PM, Sylwester Nawrocki wrote: > On 08/05/2013 06:53 PM, Stephen Warren wrote: >> On 08/03/2013 03:41 PM, Sylwester Nawrocki wrote: >>> On 08/02/2013 05:02 PM, Arun Kumar K wrote: >>>> The patch adds the DT binding documentation for Samsung &

Re: [RFC v3 02/13] [media] exynos5-fimc-is: Add Exynos5 FIMC-IS device tree bindings documentation

On 08/03/2013 03:41 PM, Sylwester Nawrocki wrote: > On 08/02/2013 05:02 PM, Arun Kumar K wrote: >> The patch adds the DT binding documentation for Samsung >> Exynos5 SoC series imaging subsystem (FIMC-IS). >> diff --git >> a/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt >> b/Document

Re: [PATCH] ARM: EXYNOS: add power domains support for EXYNOS5440

be > done later). > > Signed-off-by: Bartlomiej Zolnierkiewicz > Signed-off-by: Myungjoo Ham > Cc: Tomasz Figa > Cc: Stephen Warren > --- > Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 33 ++ > arch/arm/boot/dts/exynos5440.dtsi

Re: [PATCH 01/11] spi: Provide core support for runtime PM during transfers

factor all of this out > into the core with a flag to enable the behaviour. Patch 1, 9, 10, 11, Reviewed-by: Stephen Warren -- 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/3] ARM: exynos5420: dt: add clock entries to watchdog node

On 07/24/2013 07:14 AM, Tomasz Figa wrote: > On Wednesday 24 of July 2013 16:51:06 Sachin Kamat wrote: ... >> This is contrary to the fact that we disable everything by default in >> the top level dt files and only enable them as required in the board >> dts files. > > No, we don't disable everyth

Re: [PATCH 01/15] drivers: phy: add generic PHY framework

On 07/19/2013 12:36 AM, Kishon Vijay Abraham I wrote: > Hi, > > On Friday 19 July 2013 11:59 AM, Greg KH wrote: >> On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote: >>> Hi, >>> >>> On Friday 19 July 2013 11:13 AM, Greg KH wrote: On Fri, Jul 19, 2013 at 11:07:10AM +0530,

Re: Pulls and drive strengths in the pinctrl world

On 05/19/2013 03:17 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: ... > how a pin can not have mux? Well, if that's the way HW is designed, that's just the way it is. There are certainly pins on Tegra which don't have a mux in HW, but have some configuration options such as drive strength that can

Re: Pulls and drive strengths in the pinctrl world

On 05/18/2013 10:30 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 16:57 Sat 18 May , Tomasz Figa wrote: ... >> Personally I'd prefer a solution with separate property for each >> parameter, because it's much more flexible and allows shorter lines, >> making device tree sources more readabl

Re: Pulls and drive strengths in the pinctrl world

On 05/15/2013 06:13 PM, Tomasz Figa wrote: > On Wednesday 15 of May 2013 16:55:37 Doug Anderson wrote: >> Tomasz / Linus, >> >> On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa > wrote: >>> Yes. I don't like the current way too much either, duplication being >>> one of the reasons. >> >> Do you have

Re: Pulls and drive strengths in the pinctrl world

On 05/15/2013 12:29 PM, Linus Walleij wrote: > On Wed, May 15, 2013 at 6:44 PM, Doug Anderson wrote: ... >> Here's how I need to do things when I'm using "just an interrupt": >> >> pinctrl@1140 { >> cyapa_irq: cyapa-irq { >> samsung,pins = "gpx1-2"; >> samsung,pin-function =

Re: [RFC 23/42] drivers/spi: don't check resource with devm_ioremap_resource

On 05/10/2013 02:17 AM, Wolfram Sang wrote: > devm_ioremap_resource does sanity checks on the given resource. No need to > duplicate this in the driver. > diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c > - r = platform_get_resource(pdev, IORESOURCE_MEM, 0); > - if (!

Re: GENERIC_GPIO considered deprecated

On 04/08/2013 01:31 AM, Kukjin Kim wrote: > Alexandre Courbot wrote: >> >> On Wed, Apr 3, 2013 at 5:35 PM, Kukjin Kim wrote: could you amend the patches that adds them such as they get changed into "select ARCH_REQUIRE_GPIOLIB" instead? You can grep for "select >>> >>> I can do it for my

Re: [PATCH V4 8/9] ARM: tegra: Provide regulator to pwm-backlight

On 03/19/2013 12:59 PM, Andrew Chew wrote: > The pwm-backlight driver now takes a mandatory regulator that is gotten > during driver probe. Initialize a dummy regulator to satisfy this > requirement. I assume these patches will get merged through the PWM tree? If so, Acked-by: Steph

Re: [PATCH V4 9/9] pwm_bl: Add mandatory backlight enable regulator

On 03/19/2013 12:59 PM, Andrew Chew wrote: > Many backlights need to be explicitly enabled. Typically, this is done > with a GPIO. For flexibility, we generalize the enable mechanism to a > regulator. > > If an enable regulator is not needed, then a dummy regulator can be given > to the backligh

Re: [PATCH V4 6/9] ARM: mxs: Provide regulator to pwm-backlight

On 03/19/2013 03:27 PM, Marek Vasut wrote: > Dear Andrew Chew, > >> The pwm-backlight driver now takes a mandatory regulator that is gotten >> during driver probe. Initialize a dummy regulator to satisfy this >> requirement. >> >> Signed-off-by: Andrew Chew > > Do we really need a mandatory reg

Re: [PATCH] ARM: dts: add interrupt-names property to get interrupt resource by name

On 03/18/2013 04:27 PM, Rob Herring wrote: > On 03/18/2013 01:11 PM, Stephen Warren wrote: >> On 03/18/2013 09:50 AM, Rob Herring wrote: >>> On 03/13/2013 05:42 PM, Sylwester Nawrocki wrote: >>>> Rob, >>>> >>>> On 03/13/2013 03:39 PM, Rob He

Re: [PATCH] ARM: dts: add interrupt-names property to get interrupt resource by name

On 03/18/2013 09:50 AM, Rob Herring wrote: > On 03/13/2013 05:42 PM, Sylwester Nawrocki wrote: >> Rob, >> >> On 03/13/2013 03:39 PM, Rob Herring wrote: >>> I fail to see what the hack is. The order of interrupt properties must >>> be defined by the binding. interrupt-names is auxiliary data and mus

Re: State of pinctrl and exynos5250?

On 03/07/2013 09:27 AM, Doug Anderson wrote: > +the proper address for Will. Sorry... > > > On Thu, Mar 7, 2013 at 8:13 AM, Doug Anderson <mailto:diand...@chromium.org>> wrote: > > Linus, > > +dw_mmc folks and Stephen Warren : for context here, we

Re: [PATCH v4 02/10] s5p-fimc: Add device tree support for FIMC devices

On 02/12/2013 03:39 PM, Sylwester Nawrocki wrote: > On 02/11/2013 10:50 PM, Stephen Warren wrote: >> On 02/09/2013 03:29 PM, Sylwester Nawrocki wrote: >>> On 02/09/2013 01:32 AM, Stephen Warren wrote: >>>> On 02/08/2013 05:05 PM, Sylwester Nawrocki wrote: >>

Re: [PATCH v4 02/10] s5p-fimc: Add device tree support for FIMC devices

On 02/09/2013 03:29 PM, Sylwester Nawrocki wrote: > On 02/09/2013 01:32 AM, Stephen Warren wrote: >> On 02/08/2013 05:05 PM, Sylwester Nawrocki wrote: >>> On 02/09/2013 12:21 AM, Stephen Warren wrote: >>>> On 02/08/2013 04:16 PM, Sylwester Nawrocki wrote: >>

Re: [PATCH v4 02/10] s5p-fimc: Add device tree support for FIMC devices

On 02/08/2013 05:05 PM, Sylwester Nawrocki wrote: > On 02/09/2013 12:21 AM, Stephen Warren wrote: >> On 02/08/2013 04:16 PM, Sylwester Nawrocki wrote: >>> On 02/07/2013 12:40 AM, Stephen Warren wrote: >>>>> diff --git >>>>> a/Documentation/device

Re: [PATCH v4 01/10] s5p-csis: Add device tree support

On 02/08/2013 03:29 PM, Sylwester Nawrocki wrote: > On 02/07/2013 12:36 AM, Stephen Warren wrote: >> On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote: >>> s5p-csis is platform device driver for MIPI-CSI frontend to the FIMC >>> device. This patch support for binding

Re: [PATCH v4 02/10] s5p-fimc: Add device tree support for FIMC devices

On 02/08/2013 04:16 PM, Sylwester Nawrocki wrote: > On 02/07/2013 12:40 AM, Stephen Warren wrote: >>> diff --git >>> a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt >>> b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt >> >>

Re: [PATCH v4 06/10] s5p-fimc: Use pinctrl API for camera ports configuration

On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote: > Before the camera ports can be used the pinmux needs to be configured > properly. This patch adds a function to set the camera ports pinctrl > to a default state within the media driver's probe(). > The camera port(s) are then configured for the v

Re: [PATCH v4 05/10] s5p-fimc: Add device tree based sensors registration

On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote: > The sensor (I2C and/or SPI client) devices are instantiated by their > corresponding control bus drivers. Since the I2C client's master clock > is often provided by a video bus receiver (host interface) or other > than I2C/SPI controller device, t

Re: [PATCH v4 02/10] s5p-fimc: Add device tree support for FIMC devices

On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote: > This patch adds support for FIMC devices instantiated from devicetree > for S5PV210 and Exynos4 SoCs. The FIMC IP features include colorspace > conversion and scaling (mem-to-mem) and parallel/MIPI CSI2 bus video > capture interface. > > Multiple

Re: [PATCH v4 01/10] s5p-csis: Add device tree support

On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote: > s5p-csis is platform device driver for MIPI-CSI frontend to the FIMC > device. This patch support for binding the driver to the MIPI-CSIS > devices instantiated from device tree and for parsing all SoC and > board specific properties. > diff --gi

Re: [PATCH v3 1/3] drm/exynos: Get HDMI version from device tree

On 02/05/2013 05:56 PM, Sean Paul wrote: > On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren wrote: >> On 02/05/2013 05:37 PM, Sean Paul wrote: >>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren >>> wrote: >>>> n 02/05/2013 04:42 PM, Sean Paul wrote: >&g

Re: [PATCH v3 1/3] drm/exynos: Get HDMI version from device tree

On 02/05/2013 05:37 PM, Sean Paul wrote: > On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren wrote: >> n 02/05/2013 04:42 PM, Sean Paul wrote: >>> Use the compatible string in the device tree to determine which >>> registers/functions to use in the HDMI driver. Also chan

  1   2   >