Re: [GIT PULL 5/9] ARM: EXYNOS: Drivers for v4.5

2015-12-24 Thread Linus Walleij
On Wed, Dec 2, 2015 at 2:39 AM, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:

> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>
>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>
> are available in the git repository at:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> tags/samsung-drivers-4.5
>
> for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36:
>
>   pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 
> +0900)

OK I pulled this into the pinctrl tree, cheers!

Yours,
Linus Walleij
--
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] Add support for monitoring gpio switches

2015-12-22 Thread Linus Walleij
On Wed, Dec 16, 2015 at 11:11 AM, Martyn Welch
<martyn.we...@collabora.co.uk> wrote:

>> Patches like that has however already been suggested, and I have NACKed
>> them because the GPIO sysfs ABI is insane, and that is why I am
>> refactoring
>> the world to create a proper chardev ABI for GPIO instead. See:
>> http://marc.info/?l=linux-gpio=144550276512673=2
>
> I can certainly understand the rationale for the changes that you are
> proposing, though do worry that it does make it a bit tougher to use from
> scripting languages.

The idea is to provide commandline tools in the kernel tools/gpio subdir
to satisfy the needs of scripting. "lsgpio" today is just one example,
nothing stops us from having a tool called just "gpio-sak"
(GPIO swiss army knife) that will be tailored for scripting.

> I see that the question of how to provide functionality
> equivalent to the above was raised and no answer was forthcoming. Is there a
> plan for supporting the identification of a GPIO line serving a specific
> purpose?

Yes by name.

> What is the status of the mentioned patch series?

They stubled into a few dozen architecture issues in the GPIO
subsystem so I am busy refactoring the whole know universe :D

But I still intend to persue the series.

Yours,
Linus Walleij
--
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] Device tree binding documentation for gpio-switch

2015-12-14 Thread Linus Walleij
On Fri, Dec 11, 2015 at 3:06 PM, Rob Herring <robh...@kernel.org> wrote:
> On Fri, Dec 11, 2015 at 6:39 AM, Linus Walleij <linus.wall...@linaro.org> 
> wrote:
>> On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch
>> <martyn.we...@collabora.co.uk> wrote:
>>
>>> This patch adds documentation for the gpio-switch binding. This binding
>>> provides a mechanism to bind named links to gpio, with the primary
>>> purpose of enabling standardised access to switches that might be standard
>>> across a group of devices but implemented differently on each device.
>>>
>>> Signed-off-by: Martyn Welch <martyn.we...@collabora.co.uk>
>>
>> As mentioned in the comment to the second patch, this solves the
>> following generic problem:
>>
>> Expose a GPIO line to userspace using a specific name
>>
>> That means basically naming GPIO lines and marking them as
>> "not used by the operating system".
>>
>> This is something that has been proposed before, and postponed
>> because the kernel lacks the right infrastructure.
>
> That doesn't necessarily mean we can't define a binding.

Yeah that's true. just saying that the other stuff was not merged
for this reason, but then we can have a look at Markus' bindings
in parallell, Markus can you repost them to this audience? Only
the bindings I mean.

>> Markus Pargmann also did a series that add initial values to
>> hogs, which is the inverse usecase of this, where you want to
>> *output* something by default, then maybe also make it available
>> to userspace.
>>
>> So what we need to see here is a patch series that does all of these
>> things:
>>
>> - Name lines
>>
>> - Sets them to initial values
>>
>> - Mark them as read-only
>>
>> - Mark them as "not used by the operating system" so that they
>>   can be default-exported to userspace.
>
> No! This should not be a DT property.
>
> Whether I want to control a GPIO in the kernel or userspace is not
> known and can change over time. It could simply depend on kernel
> config. There is also the case that a GPIO has no connection or kernel
> driver until some time later when a DT overlay for an expansion board
> is applied.

That's correct. So from a DT point of view, what really matters is
to give things a name, and the hogs and initvals syntax already
has a structure for this that is in use
(from Documentation/devicetree/bindings/gpio/gpio.txt):

qe_pio_a: gpio-controller@1400 {
compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
reg = <0x1400 0x18>;
gpio-controller;
#gpio-cells = <2>;

line_b {
gpio-hog;
gpios = <6 0>;
output-low;
line-name = "foo-bar-gpio";
};
};

Markus use this also for initial values. That could easily be used in
a budget version like this:

line_b {
/* Just naming */
gpios = <6 0>;
line-name = "foo-bar-gpio";
};

That could grow kind of big though. Or maybe not? How many
GPIO lines are actually properly named in a typical system?

The problem is that naming is usually imposed by consumers (they
are the ones who know how the line is used).

And then I do not mean naming it after the pin on the capsule
where it comes out as per the datasheet, but
naming it after the actual use.

Naming it after the hardware specs is something the operating
system can do, in Linux' case by the array char *names; inside the
struct gpio_chip and should not be part of the bindings IMO.

I would rather imagine this is something used in a top-level board
file naming it: "header-2-22" for the 22nd pin on some second header
on my BeagleBone Black or something like that. And those may not
be so vast in numbers so they could be named using this pattern.

Yours,
Linus Walleij
--
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 004/182] gpio: generic: factor into gpio_chip struct

2015-12-13 Thread Linus Walleij
On Thu, Dec 10, 2015 at 12:08 AM, Michael Welling <mwell...@ieee.org> wrote:
> On Wed, Dec 09, 2015 at 02:12:40PM +0100, Linus Walleij wrote:
> ...
>> - ret = gpiochip_add(>gc);
>> + ret = gpiochip_add_data(gc, NULL);
>>   if (ret) {
>
> gpiochip_add is still mentioned in the dev_err below.

I explicitly left text string updates aside, I am anyways going to have to go
over all drivers for a second refactoring with gpiodev_alloc() etc.

Yours,
Linus Walleij
--
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] Device tree binding documentation for gpio-switch

2015-12-11 Thread Linus Walleij
On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch
<martyn.we...@collabora.co.uk> wrote:

> This patch adds documentation for the gpio-switch binding. This binding
> provides a mechanism to bind named links to gpio, with the primary
> purpose of enabling standardised access to switches that might be standard
> across a group of devices but implemented differently on each device.
>
> Signed-off-by: Martyn Welch <martyn.we...@collabora.co.uk>

As mentioned in the comment to the second patch, this solves the
following generic problem:

Expose a GPIO line to userspace using a specific name

That means basically naming GPIO lines and marking them as
"not used by the operating system".

This is something that has been proposed before, and postponed
because the kernel lacks the right infrastructure.

Markus Pargmann also did a series that add initial values to
hogs, which is the inverse usecase of this, where you want to
*output* something by default, then maybe also make it available
to userspace.

So what we need to see here is a patch series that does all of these
things:

- Name lines

- Sets them to initial values

- Mark them as read-only

- Mark them as "not used by the operating system" so that they
  can be default-exported to userspace.

Making *USE* of this naming etc inside the Linux kernel

> +gpio-switch {
> +compatible = "gpio-switch";
> +
> +write-protect {
> +label = "write-protect";
> +gpios = < 0 GPIO_ACTIVE_LOW>;
> +read-only;
> +};

This should not need new structures and nodes like this. It should
be part of Documentation/devicetree/bindings/gpio/gpio.txt
and put directly in the gpiochip node.

Maybe as an extension of the existing hogs, but that has already
been tried.

While we can agree on a device tree binding, the kernel still needs
major refactoring to actually expose named GPIOs to userspace,
and that should be done using the new chardev, not with sysfs
links.

Yours,
Linus Walleij
--
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] Add support for monitoring gpio switches

2015-12-11 Thread Linus Walleij
On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch
<martyn.we...@collabora.co.uk> wrote:

> Select Chromebooks have gpio attached to switches used to cause the
> firmware to enter alternative modes of operation and/or control other
> device characteristics (such as write protection on flash devices). This
> patch adds a driver that exposes a read-only interface to allow these
> signals to be read from user space.
>
> This functionality has been generalised to provide support for any device
> with device tree support which needs to identify a gpio as being used for a
> specific task.
>
> Signed-off-by: Martyn Welch <martyn.we...@collabora.co.uk>

If you want to do this thing, also propose a device tree binding document
for "gpio-switch".

But first (from Documentation/gpio/drivers-on-gpio.txt):

- gpio-keys: drivers/input/keyboard/gpio_keys.c is used when your GPIO line
  can generate interrupts in response to a key press. Also supports debounce.

- gpio-keys-polled: drivers/input/keyboard/gpio_keys_polled.c is used when your
  GPIO line cannot generate interrupts, so it needs to be periodically polled
  by a timer.

- extcon-gpio: drivers/extcon/extcon-gpio.c is used when you need to read an
  external connector status, such as a headset line for an audio driver or an
  HDMI connector. It will provide a better userspace sysfs interface than GPIO.

So you mean none of these apply for this case?

Second: what you want to do is export a number of GPIOs with certain names
to userspace. This is something very generic and should be implemented
as such, not as something Chromebook-specific.

Patches like that has however already been suggested, and I have NACKed
them because the GPIO sysfs ABI is insane, and that is why I am refactoring
the world to create a proper chardev ABI for GPIO instead. See:
http://marc.info/?l=linux-gpio=144550276512673=2

So for the moment, NACK on this, please participate in creating the
*right* ABI for GPIO instead of trying to shoehorn stuff into the dying
sysfs ABI.

Yours,
Linus Walleij
--
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 6/6] pinctrl: samsung: Remove unneded semicolon

2015-10-02 Thread Linus Walleij
On Wed, Sep 16, 2015 at 1:28 AM, Javier Martinez Canillas
<jav...@osg.samsung.com> wrote:

> It's not needed an is just creating a null statement, so remove it.
>
> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>

Patch applied with Krzysztof's Review-tag.

Yours,
Linus Walleij
--
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] Watchdog: Fix parent of watchdog_devices

2015-08-26 Thread Linus Walleij
On Tue, Aug 18, 2015 at 6:34 PM, Pratyush Anand pan...@redhat.com wrote:

 /sys/class/watchdog/watchdogn/device/modalias can help to identify the
 driver/module for a given watchdog node. However, many wdt devices does not 
 set
 its parent and so, we do not see an entry for device in sysfs for such 
 devices.

 This patch fixes parent of watchdog_device so that
 /sys/class/watchdog/watchdogn/device is populated.

 Exceptions: booke, diag288, mpc8xxx, octeon, softdog and w83627hf -- They do 
 not
 have any parent. Not sure, how we can we identify driver for these devices.

 Signed-off-by: Pratyush Anand pan...@redhat.com

Acked-by: Linus Walleij linus.wall...@linaro.org

Yours,
Linus Walleij
--
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] pinctrl: kill off set_irq_flags usage

2015-07-28 Thread Linus Walleij
On Mon, Jul 27, 2015 at 10:55 PM, Rob Herring r...@kernel.org wrote:

 set_irq_flags is ARM specific with custom flags which have genirq
 equivalents. Convert drivers to use the genirq interfaces directly, so we
 can kill off set_irq_flags. The translation of flags is as follows:

 IRQF_VALID - !IRQ_NOREQUEST
 IRQF_PROBE - !IRQ_NOPROBE
 IRQF_NOAUTOEN - IRQ_NOAUTOEN

 For IRQs managed by an irqdomain, the irqdomain core code handles clearing
 and setting IRQ_NOREQUEST already, so there is no need to do this in
 .map() functions and we can simply remove the set_irq_flags calls. Some
 users also modify IRQ_NOPROBE and this has been maintained although it
 is not clear that is really needed. There appears to be a great deal of
 blind copy and paste of this code.

 Signed-off-by: Rob Herring r...@kernel.org
 Acked-by: Linus Walleij linus.wall...@linaro.org
 Cc: Stephen Warren swar...@wwwdotorg.org
 Cc: Lee Jones l...@kernel.org
 Cc: Matthias Brugger matthias@gmail.com
 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: Thomas Abraham thomas.abra...@linaro.org
 Cc: Kukjin Kim kg...@kernel.org
 Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
 Cc: linux-g...@vger.kernel.org
 Cc: linux-rpi-ker...@lists.infradead.org
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux-media...@lists.infradead.org
 Cc: linux-samsung-soc@vger.kernel.org
 ---
 Thomas asked that this be merged thru subsystem trees instead of arm-soc,
 so please apply this to your tree.

Patch applied, and thanks for driving this.

Yours,
Linus Walleij
--
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] MAINTAINERS: pinctrl: Move Thomas Abraham to CREDITS

2015-07-28 Thread Linus Walleij
On Tue, Jul 28, 2015 at 10:21 AM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:

 Thomas Abraham's Linaro email address bounces for several months. Also
 there were no replies for several emails sent on LKML to his Samsung
 address. Move his name to CREDITS.

 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: Thomas Abraham thomas...@samsung.com
 Cc: Linus Walleij linus.wall...@linaro.org
 Link: http://lkml.org/lkml/2015/6/15/15

Patch applied.

Yours,
Linus Walleij
--
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/2] pinctrl: samsung: don't truncate the last char

2015-07-16 Thread Linus Walleij
On Mon, Jun 22, 2015 at 5:12 PM, Dan Carpenter dan.carpen...@oracle.com wrote:

 We were allocating enough space because sizeof(-grp) and
 sizeof(-mux) are both equal to 5 but in the snprintf() we only allowed
 for 4 characters so the last 'p' and 'x' characters were truncated.

 The allocate and sprintf can be done in one step with the kasprintf().

 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com

Patch applied with Krzysztof's review tag.

Yours,
Linus Walleij
--
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] pinctrl: samsung: Remove old unused defines

2015-06-30 Thread Linus Walleij
On Mon, Jun 15, 2015 at 6:54 AM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:

 Since 9a2c1c3b91aa (pinctrl: samsung: Allow grouping multiple
 pinmux/pinconf nodes) the defines for GPIO group and function names are
 not used anywhere in the driver.

 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Inspired-by: Dan Carpenter dan.carpen...@oracle.com

Patch applied.

Yours,
Linus Walleij
--
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/21] On-demand device registration

2015-06-15 Thread Linus Walleij
On Sat, Jun 13, 2015 at 8:27 PM, Alexander Holler hol...@ahsoftware.de wrote:

 And because you've said that problem space is a bit convoluted and I
 disagree, here's a summary from my point of view:

 1. All the necessary information (dependencies between drivers) already
 exists at compile time. The set of dependencies between drivers might become
 smaller by configuration, but will not become larger. So there should be NO
 need to collect them at runtime, e.g. by instrumenting function calls.

I think you arrived at the core of the crux here.

When we look up a resource provided from another driver, e.g. from
regulator_get(), clk_get(), pinctrl_get(), gpiod_get() etc - the dependency
is resolved by looking in a cross-reference table for either a struct device*
pointer or a string, an index, or both or all three. Examples:

struct regulator *regulator_get(struct device *dev, const char *id);
struct clk *clk_get(struct device *dev, const char *id);
struct gpio_desc *__must_check __gpiod_get(struct device *dev,
 const char *con_id,
 enum gpiod_flags flags);
(...)

(*_index() variants exist on some of the resource retrieveal
functions.)

struct device * is the device requesting the resource, con_id
is the string name of the resource on the provider side. This is all
solved by looking in cross reference tables. ONE way of resolving
that cross reference is to look into the device tree or the ACPI table.
But for the board file case, this is resolved at runtime by the cross
reference table, registered with calls such as gpiod_add_lookup_table().

It is true that in the theoretical sense, all of this exist at compile time
especially if you can parse something like a device tree and
figure out what struct device * nodes will correspond to the struct
device_node:s in it. For ACPI I guess a similar procedure is viable.

Problem: this requires the kernel compile to know exactly *which* device tree
or ACPI table it is going to boot on. The expressed goal of device tree
and ACPI is to have *ONE* kernel booting several device trees.
Here your approach stops short: you are suggesting instrumenting
the kernel at compile time to one single device tree or ACPI table.
But we never know really what device tree or ACPI table will be used.
This just cannot be done at compile time for that reason alone.

Example: in boot case (A) the regulator may be provided by regulator
foo driver on an i2c bus. But in boot case (B) the very same regulator
may be provided by regulator bar on an SPI bus. These are very
real usecases, for example for drivers/net/ethernet/smsc/smsc911x.c,
will get regulators from the most diverse places depending on what
device tree is used.

For board files, it is neither possible in theory: you need to compile the
code to figure out the struct device * provider, and/or the string name
of the providing device (.name field in struct device for the provider)
to resolve dependencies at compile time.

For the board file case, resolving dependencies at compile time will
require a quite complex two-stage rocket: compile the code to
get resources out, then recompile with known resources.

I guess your suggested approach then need to introduce a special
build tool to order the initcalls accordingly.

Again this will fall short if you don't know at compile time exactly
*which* board file will be executed.

So the only practical way to solve this at compile time is to predict
an initcall ordering sequence for all possible boot paths, compile in
all of them, and choose the right one at boot. But the number of boot
paths is equal to the number of device trees / ACPI tables or
board files supported, and that space is uncontrolled and ordered
infinite.

Basically I think the root problem with your approach is that you
assume we know what hardware we will boot on at compile time. We
discarded that development path years ago. We have no clue, this
is resolved at runtime. Alas, people still create super-optimized
systems using exactly this knowledge, but it is not our main target
here, it is a special optimization case.

Yours,
Linus Walleij
--
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/21] On-demand device registration

2015-06-12 Thread Linus Walleij
On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler hol...@ahsoftware.de wrote:
 Am 11.06.2015 um 14:30 schrieb Linus Walleij:

 Certainly it is possible to create deadlocks in this scenario, but the
 scope is not to create an ubreakable system.

 IAnd what happens if you run into a deadlock? Do you print you've lost, try
 changing your kernel config in some output hidden by a splash-screen? ;)

Sorry it sounds like a blanket argument, the fact that there are
mutexes in the kernel makes it possible to deadlock, it doesn't
mean we don't use mutexes. Some programming problems are
just like such.

Yours,
Linus Walleij
--
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/21] On-demand device registration

2015-06-11 Thread Linus Walleij
On Thu, Jun 11, 2015 at 12:17 PM, Alexander Holler hol...@ahsoftware.de wrote:
 Am 11.06.2015 um 10:12 schrieb Linus Walleij:
 On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler hol...@ahsoftware.de
 wrote:

 You would end up with the same problem of deadlocks as currently, and you
 would still need something ugly like the defered probe brutforce to avoid
 them.


 Sorry I don't get that. Care to elaborate on why?


 Because loading/initializing on demand doesn't give you any solved order of
 drivers to initialize. And it can't because it has no idea about the
 requirements of other drivers. The reason why it might work better in the
 case of the tegra is that it might give you another initialization order
 than the one which is currently choosen, which, by luck, might be a better
 one.

 But maybe I missed something, I haven't looked at the patches at all. But
 just loading on demand, can't magically give you a working order of drivers
 to initialize. E.g. how do you choose the first driver to initialize?

So the current patch set introduces dependencies (just for device tree)
and Tomeu is working on a more generic dependency approach for
any HW description.

The first driver to initialize will be as usual the first one in the list for
that initlevel, then walking up the initilevels.

However if any driver runs into a resource roadblock it will postpone
and wait for dependencies to probe first.

Certainly it is possible to create deadlocks in this scenario, but the
scope is not to create an ubreakable system.

Yours,
Linus Walleij
--
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/21] On-demand device registration

2015-06-11 Thread Linus Walleij
On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler hol...@ahsoftware.de wrote:
 Am 10.06.2015 um 09:30 schrieb Linus Walleij:

 i2c host comes out, probes the regulator driver, regulator driver
 probes and then the regulator_get() call returns.

 This requires instrumentation on anything providing a resource
 to another driver like those I mentioned and a lot of overhead
 infrastructure, but I think it's the right approach. However I don't
 know if I would ever be able to pull that off myself, I know talk
 is cheap and I should show the code instead.

 You would end up with the same problem of deadlocks as currently, and you
 would still need something ugly like the defered probe brutforce to avoid
 them.

Sorry I don't get that. Care to elaborate on why?

Yours,
Linus Walleij
--
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/21] On-demand device registration

2015-06-11 Thread Linus Walleij
On Wed, Jun 10, 2015 at 12:19 PM, Tomeu Vizoso
tomeu.viz...@collabora.com wrote:
 On 10 June 2015 at 09:30, Linus Walleij linus.wall...@linaro.org wrote:

 regulator_get(...) - not available, so:
 - identify target regulator provider - this will need instrumentation
 - probe it

 It then turns out the regulator driver is on the i2c bus, so we
 need to probe the i2c driver:
 - identify target i2c host for the regulator driver - this will need
   instrumentation
 - probe the i2c host driver

 i2c host comes out, probes the regulator driver, regulator driver
 probes and then the regulator_get() call returns.

 Hmm, if I understand correctly what you say, this is exactly what this
 particular series does:

 regulator_get - of_platform_device_ensure - probe() on the platform
 device that encloses the requested device node (i2c host) - i2c slave
 gets probed and the regulator registered - regulator_get returns the
 requested resource

Yes. But only for device tree.

 The downside I'm currently looking at is that an explicit dependency
 graph would be useful to have for other purposes. For example to print
 a neat warning when a dependency cannot be fulfilled. Or to refuse to
 unbind a device which other devices depend on, or to automatically
 unbind the devices that depend on it, or to print a warning if a
 device is hotplugged off and other devices depend on it.

Unbind/remove() calls are the inverse usually yes.

But also the [runtime] power up/down sequences for the
devices tend to depend on a similar ordering or mostly
the same. (Mentioned this before I think.)

 This requires instrumentation on anything providing a resource
 to another driver like those I mentioned and a lot of overhead
 infrastructure, but I think it's the right approach. However I don't
 know if I would ever be able to pull that off myself, I know talk
 is cheap and I should show the code instead.

 Yeah, if you can give it a second look and say if it matches what you
 wrote above, it would be very much appreciated.

Yes you are right. But what about ACPI, board files,
Simple Firmware and future hardware description languages...

Yours,
Linus Walleij
--
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/21] On-demand device registration

2015-06-10 Thread Linus Walleij
On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso
tomeu.viz...@collabora.com wrote:
 On 2 June 2015 at 10:48, Linus Walleij linus.wall...@linaro.org wrote:

 This is what systemd is doing in userspace for starting services:
 ask for your dependencies and wait for them if they are not
 there. So drivers ask for resources and wait for them. It also
 needs to be abstract, so for example we need to be able to
 hang on regulator_get() until the driver is up and providing that
 regulator, and as long as everything is in slowpath it should
 be OK. (And vice versa mutatis mutandis for clk, gpio, pin
 control, interrupts (!) and DMA channels for example.)

 I understood above that you propose probing devices in order, but now
 you mention that resource getters would block until the dependency is
 fulfilled which confuses me because if we are probing in order then
 all dependencies would be fulfilled before the device in question gets
 probed.

Sorry, the problem space is a bit convoluted so the answers
get a bit convoluted. Maybe I'm thinking aloud and altering the course
of my thoughts as I type...

I guess there can be explicit dependencies for resources like this
patch does, but another way would be for all resource fetch functions
to be instrumented, so that you do not block until you try to take
a resource that is not yet there, e.g.:

regulator_get(...) - not available, so:
- identify target regulator provider - this will need instrumentation
- probe it

It then turns out the regulator driver is on the i2c bus, so we
need to probe the i2c driver:
- identify target i2c host for the regulator driver - this will need
  instrumentation
- probe the i2c host driver

i2c host comes out, probes the regulator driver, regulator driver
probes and then the regulator_get() call returns.

This requires instrumentation on anything providing a resource
to another driver like those I mentioned and a lot of overhead
infrastructure, but I think it's the right approach. However I don't
know if I would ever be able to pull that off myself, I know talk
is cheap and I should show the code instead.

Deepest respect for your efforts!

Yours,
Linus Walleij
--
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 11/15] pinctrl: kill off set_irq_flags usage

2015-06-10 Thread Linus Walleij
On Tue, Jun 9, 2015 at 8:26 PM, Rob Herring r...@kernel.org wrote:

 set_irq_flags is ARM specific with custom flags which have genirq
 equivalents. Convert drivers to use the genirq interfaces directly, so we
 can kill off set_irq_flags. The translation of flags is as follows:

 IRQF_VALID - !IRQ_NOREQUEST
 IRQF_PROBE - !IRQ_NOPROBE
 IRQF_NOAUTOEN - IRQ_NOAUTOEN

 For IRQs managed by an irqdomain, the irqdomain core code handles clearing
 and setting IRQ_NOREQUEST already, so there is no need to do this in
 .map() functions and we can simply remove the set_irq_flags calls. Some
 users also set IRQ_NOPROBE and this has been maintained although it is not
 clear that is really needed. There appears to be a great deal of blind
 copy and paste of this code.

 Signed-off-by: Rob Herring r...@kernel.org
 Cc: Linus Walleij linus.wall...@linaro.org
 Cc: Stephen Warren swar...@wwwdotorg.org
 Cc: Lee Jones l...@kernel.org
 Cc: Matthias Brugger matthias@gmail.com
 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: Thomas Abraham thomas.abra...@linaro.org
 Cc: Kukjin Kim kg...@kernel.org
 Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
 Cc: linux-g...@vger.kernel.org
 Cc: linux-rpi-ker...@lists.infradead.org
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux-media...@lists.infradead.org
 Cc: linux-samsung-soc@vger.kernel.org

Acked-by: Linus Walleij linus.wall...@linaro.org

Yours,
Linus Walleij
--
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/21] On-demand device registration

2015-06-02 Thread Linus Walleij
On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso
tomeu.viz...@collabora.com wrote:

 have looked into ordered probing as a
 better way of solving this than moving nodes around in the DT or playing with
 initcall levels.

 While reading the thread [1] that Alexander Holler started with his series to
 make probing order deterministic, it occurred to me that it should be possible
 to achieve the same by registering devices as they are referenced by other
 devices.

This is pretty cool, but a too local solution to a global problem.

Deferred probe and initcall reordering, silly as they may seem,
does not require you to use device tree.

The real solution, which I think I pointed out already when we
added deferred probe, is to put dependency graphs in the drivers
and have the kernel device driver core percolate dependecies by
walking the graph on probing driver, removing driver (usually the
inverse use case), [runtime] suspend and [runtime] resumeing
a driver. Possibly the dependencies will even be different
depending on use case.

This is what systemd is doing in userspace for starting services:
ask for your dependencies and wait for them if they are not
there. So drivers ask for resources and wait for them. It also
needs to be abstract, so for example we need to be able to
hang on regulator_get() until the driver is up and providing that
regulator, and as long as everything is in slowpath it should
be OK. (And vice versa mutatis mutandis for clk, gpio, pin
control, interrupts (!) and DMA channels for example.)


So if this should be solved it should be solved in an abstract way
in the device driver core available for all, then have calls calling
out to DT, ACPI, possibly even PCI or USB (as these
enumerate devices themselves) to obtain a certain
dependency.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] RFT: pinctrl: samsung: separate wakeup irqdomain

2015-04-09 Thread Linus Walleij
The Samsung pin control driver and subdrivers sometimes use both
an irqdomain for some IRQs and another irqdomain for wakeup irqs,
registering the first with a call to the per-SoC callback
.eint_gpio_init() and the second with a call to .eint_wkup_init()
however it seems both runpaths will assign the resulting irqdomain
to the per-bank bank.irq_domain member, making the second
(wakeup) irqdomain overwrite the first one.

I'm surprised this even works, and it seems that the S3C
per-domain domain data that seems to be used in part to work
around this bug by creating a local array with copies of the
irqdomain (!).

This patch mainly adds a new record to the GPIO/pin bank
for wakeups and use this in the .eint_wkup_init() callbacks
to pave the way for more cleanups.

Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
Tomasz etc: I don't know if I'm just misunderstanding this,
can you look at it and tell me how badly I misunderstand
these Samsung wakeups, to me it is a complete mystery.
---
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 6 +++---
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 6 +++---
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 6 +++---
 drivers/pinctrl/samsung/pinctrl-samsung.h | 1 +
 4 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index c8f83f96546c..6adf34e3cce6 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -469,7 +469,7 @@ static void exynos_irq_demux_eint16_31(unsigned int irq, 
struct irq_desc *desc)
+ b-eint_offset);
mask = readl(d-virt_base + b-irq_chip-eint_mask
+ b-eint_offset);
-   exynos_irq_demux_eint(pend  ~mask, b-irq_domain);
+   exynos_irq_demux_eint(pend  ~mask, b-wkup_domain);
}
 
chained_irq_exit(chip, desc);
@@ -511,9 +511,9 @@ static int exynos_eint_wkup_init(struct 
samsung_pinctrl_drv_data *d)
if (bank-eint_type != EINT_TYPE_WKUP)
continue;
 
-   bank-irq_domain = irq_domain_add_linear(bank-of_node,
+   bank-wkup_domain = irq_domain_add_linear(bank-of_node,
bank-nr_pins, exynos_eint_irqd_ops, bank);
-   if (!bank-irq_domain) {
+   if (!bank-wkup_domain) {
dev_err(dev, wkup irq domain add failed\n);
return -ENXIO;
}
diff --git a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c 
b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
index f1993f42114c..1dd1e5a0ed58 100644
--- a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
+++ b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
@@ -539,9 +539,9 @@ static int s3c24xx_eint_init(struct 
samsung_pinctrl_drv_data *d)
ops = (bank-eint_offset == 0) ? s3c24xx_gpf_irq_ops
   : s3c24xx_gpg_irq_ops;
 
-   bank-irq_domain = irq_domain_add_linear(bank-of_node,
+   bank-wkup_domain = irq_domain_add_linear(bank-of_node,
bank-nr_pins, ops, ddata);
-   if (!bank-irq_domain) {
+   if (!bank-wkup_domain) {
dev_err(dev, wkup irq domain add failed\n);
return -ENXIO;
}
@@ -553,7 +553,7 @@ static int s3c24xx_eint_init(struct 
samsung_pinctrl_drv_data *d)
break;
if (!(mask  1))
continue;
-   eint_data-domains[irq] = bank-irq_domain;
+   eint_data-domains[irq] = bank-wkup_domain;
++irq;
}
}
diff --git a/drivers/pinctrl/samsung/pinctrl-s3c64xx.c 
b/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
index 7756c1e9e763..9701424a8bea 100644
--- a/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
+++ b/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
@@ -757,9 +757,9 @@ static int s3c64xx_eint_eint0_init(struct 
samsung_pinctrl_drv_data *d)
}
ddata-bank = bank;
 
-   bank-irq_domain = irq_domain_add_linear(bank-of_node,
+   bank-wkup_domain = irq_domain_add_linear(bank-of_node,
nr_eints, s3c64xx_eint0_irqd_ops, ddata);
-   if (!bank-irq_domain) {
+   if (!bank-wkup_domain) {
dev_err(dev, wkup irq domain add failed\n);
return -ENXIO;
}
@@ -769,7 +769,7 @@ static int s3c64xx_eint_eint0_init(struct 
samsung_pinctrl_drv_data *d)
for (pin = 0; mask; ++pin, mask = 1) {
if (!(mask  1))
continue;
-   data-domains[irq] = bank-irq_domain;
+   data-domains[irq] = bank-wkup_domain

Re: [PATCH] pinctrl: exynos: Remove eint_gpio_init call-back for exynos7 alive pinctrl block

2015-03-17 Thread Linus Walleij
On Sun, Mar 1, 2015 at 5:21 PM, Abhilash Kesavan a.kesa...@samsung.com wrote:

 The alive pin controller on exynos7 does not support external gpio
 interrupts. Hence, remove the eint_gpio_init call-back for it. This
 fixes the following error message seen during exynos7 boot-up:
 samsung-pinctrl 1058.pinctrl: irq number not available

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com

Patch applied with Tomasz ACK.

Yours,
Linus Walleij
--
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] pinctrl: exynos: Remove eint_gpio_init call-back for exynos7 alive pinctrl block

2015-03-09 Thread Linus Walleij
On Sun, Mar 1, 2015 at 5:21 PM, Abhilash Kesavan a.kesa...@samsung.com wrote:

 The alive pin controller on exynos7 does not support external gpio
 interrupts. Hence, remove the eint_gpio_init call-back for it. This
 fixes the following error message seen during exynos7 boot-up:
 samsung-pinctrl 1058.pinctrl: irq number not available

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com

Tomasz, can you look at this patch?

Yours,
Linus Walleij
--
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 v4] pinctrl: exynos: Add support for Exynos5433

2015-03-06 Thread Linus Walleij
On Tue, Feb 24, 2015 at 3:47 AM, Chanwoo Choi cw00.c...@samsung.com wrote:

 This patch adds driver data for Exynos5433 SoC. Exynos5433 includes 228 multi-
 functional input/output port pins and 135 memory port pins. There are 41 
 general
 port groups and 2 memory port groups.

 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: Thomas Abraham thomas.abra...@linaro.org
 Cc: Linus Walleij linus.wall...@linaro.org
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Inki Dae inki@samsung.com
 Acked-by: Tomasz Figa tomasz.f...@gmail.com
 ---
 Changes from v3:
 - Rebase it on Linux 4.0-rc1
 - Add acked messgae of Tomasz Figa

Already merged v3. Thanks anyway!

Yours,
Linus Walleij
--
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] pinctrl: exynos: Add support for Exynos5433

2015-03-05 Thread Linus Walleij
On Wed, Jan 21, 2015 at 7:43 AM, Chanwoo Choi cw00.c...@samsung.com wrote:

 This patch adds driver data for Exynos5433 SoC. Exynos5433 includes 228 multi-
 functional input/output port pins and 135 memory port pins. There are 41 
 general
 port groups and 2 memory port groups.

 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: Thomas Abraham thomas.abra...@linaro.org
 Cc: Linus Walleij linus.wall...@linaro.org
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Inki Dae inki@samsung.com
 ---
 Changes from v2:
 - Rebase it on v3.19-rc5

Patch applied with Tomasz ACK.

Yours,
Linus Walleij
--
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] pinctrl: exynos: Add support for Exynos5433

2015-01-29 Thread Linus Walleij
On Wed, Jan 21, 2015 at 7:43 AM, Chanwoo Choi cw00.c...@samsung.com wrote:

 This patch adds driver data for Exynos5433 SoC. Exynos5433 includes 228 multi-
 functional input/output port pins and 135 memory port pins. There are 41 
 general
 port groups and 2 memory port groups.

 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: Thomas Abraham thomas.abra...@linaro.org
 Cc: Linus Walleij linus.wall...@linaro.org
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Inki Dae inki@samsung.com
 ---
 Changes from v2:
 - Rebase it on v3.19-rc5

Waiting for Tomasz to review this.

Yours,
Linus Walleij
--
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] pinctrl: exynos: Add AUDIO pin controller for exynos7

2015-01-19 Thread Linus Walleij
On Wed, Jan 14, 2015 at 3:27 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
 2015-01-14 20:40 GMT+09:00 Linus Walleij linus.wall...@linaro.org:
 On Fri, Dec 19, 2014 at 2:10 PM, Padmavathi Venna padm...@samsung.com 
 wrote:

 Audio IPs on Exynos7 require gpios available in AUDIO
 pin controller block. So adding the AUDIO pinctrl support.

 Signed-off-by: Padmavathi Venna padm...@samsung.com
 (...)
 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
 +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
 @@ -181,6 +181,7 @@ Aliases for controllers compatible with 
 samsung,exynos7-pinctrl:
  - pinctrl6: pin controller of FSYS0 block,
  - pinctrl7: pin controller of FSYS1 block,
  - pinctrl8: pin controller of BUS1 block,
 +- pinctrl9: pin controller of AUDIO block,

 This doesn't apply at all, the list has never been in the document merged
 upstream.

 I believe this patch depends on patch [1], which was mentioned in
 cover letter and which you seem to have applied two days ago. If it
 still doesn't apply, please let me know if I should collect the
 patches myself and prepare a pull request for you.

 [1] https://patchwork.kernel.org/patch/5467321/

It applied when I tried it now, sorry I must have screwed up or something :(

Patch applied!

Yours,
Linus Walleij
--
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] pinctrl: exynos: Add AUDIO pin controller for exynos7

2015-01-14 Thread Linus Walleij
On Fri, Dec 19, 2014 at 2:10 PM, Padmavathi Venna padm...@samsung.com wrote:

 Audio IPs on Exynos7 require gpios available in AUDIO
 pin controller block. So adding the AUDIO pinctrl support.

 Signed-off-by: Padmavathi Venna padm...@samsung.com
(...)
 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
 +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
 @@ -181,6 +181,7 @@ Aliases for controllers compatible with 
 samsung,exynos7-pinctrl:
  - pinctrl6: pin controller of FSYS0 block,
  - pinctrl7: pin controller of FSYS1 block,
  - pinctrl8: pin controller of BUS1 block,
 +- pinctrl9: pin controller of AUDIO block,

This doesn't apply at all, the list has never been in the document merged
upstream.

Please prepare this patch rebased on a *CLEAN* upstream tree
and resend.

Include Tomasz ACK on your repost.

Yours,
Linus Walleij
--
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 2/2] pinctrl: exynos: Add BUS1 pin controller for exynos7

2015-01-12 Thread Linus Walleij
On Wed, Dec 10, 2014 at 9:39 AM, Vivek Gautam gautam.vi...@samsung.com wrote:

 USB and Power regulator on Exynos7 require gpios available
 in BUS1 pin controller block.
 So adding the BUS1 pinctrl support.

 Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: Linus Walleij linus.wall...@linaro.org
 ---

 Changes since V2:
  - Added documentation on alias for BUS1 pin controller block.

Patch applied with Tomasz ACK.

Yours,
Linus Walleij
--
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] Documentation: dt-bindings: Add aliases information for Exynos7 pin controllers

2015-01-12 Thread Linus Walleij
On Wed, Dec 10, 2014 at 9:39 AM, Vivek Gautam gautam.vi...@samsung.com wrote:

 Adding list of aliases for supported Exynos7 pin controller blocks.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: Linus Walleij linus.wall...@linaro.org

Patch applied.

Yours,
Linus Walleij
--
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 14/21] ARM: imx6: convert GPC to stacked domains

2015-01-12 Thread Linus Walleij
On Mon, Jan 12, 2015 at 7:26 PM, Marc Zyngier marc.zyng...@arm.com wrote:

 IMX6 has been (ab)using the gic_arch_extn to provide
 wakeup from suspend, and it makes a lot of sense to convert
 this code to use stacked domains instead.

 This patch does just this, updating the DT files to actually
 reflect what the HW provides.

 BIG FAT WARNING: because the DTs were so far lying by not
 exposing the fact that the GPC block is actually the first
 interrupt controller in the chain, kernels with this patch
 applied wont have any suspend-resume facility when booted
 with old DTs, and old kernels with updated DTs won't even boot.

 Tested-by: Stefan Agner ste...@agner.ch
 Acked-by: Stefan Agner ste...@agner.ch
 Signed-off-by: Marc Zyngier marc.zyng...@arm.com

(...)

 +static int imx_gpc_domain_alloc(struct irq_domain *domain,
 + unsigned int virq,

Nutcase nitpick on this nice patch series: every time I see virq my
OCD triggers, as I think the v in virq stand for virtual. These irqs
are no more virtual than any other Linux irq numbers, hwirq is
more to the point.

I just refer to these as irq (sans v) in any code I write.

Yours,
Linus Walleij
--
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 05/15] gpio: move DT parsing code to separate functions

2015-01-12 Thread Linus Walleij
On Wed, Dec 10, 2014 at 4:48 PM, Andrzej Hajda a.ha...@samsung.com wrote:

 The patch moves Device Tree parsing logic to separate
 function.

 Signed-off-by: Andrzej Hajda a.ha...@samsung.com

I think this patch need to be rebased on the GPIO devel branch, but
looks like it makes things cleaner so can stand on its own merits.
We moves stuff around a bit in the OF code though.

Please remember to send this patch to the linux-gpio list and comaintainer
Alexandre Courbot on reposts. (Cc-tags in the patch are good
for this.)

Yours,
Linus Walleij
--
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 v4 2/3] pinctrl: exynos: Fix GPIO setup failure because domain clock being gated

2015-01-05 Thread Linus Walleij
On Fri, Dec 5, 2014 at 12:00 PM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:

 The audio subsystem on Exynos 5420 has separate clocks and GPIO. To
 operate properly on GPIOs the main block clock 'mau_epll' must be
 enabled.

 This was observed on Peach Pi/Pit and Arndale Octa (after enabling i2s0)
 after introducing runtime PM to pl330 DMA driver. After that commit the
 'mau_epll' was gated, because the amba clock was disabled and there
 were no more users of mau_epll.

 The system hang just before probing i2s0 because
 samsung_pinmux_setup() tried to access memory from audss block which was
 gated.

 Add a clock property to the pinctrl driver and enable the clock during
 GPIO setup. During normal GPIO operations (set, get, set_direction) the
 clock is not enabled.

 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

Tomasz, is this OK and should I apply it for fixes or next?

Yours,
Linus Walleij
--
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: DT on s3c24xx

2014-12-18 Thread Linus Walleij
On Thu, Dec 18, 2014 at 9:34 AM, Vasily Khoruzhick anars...@gmail.com wrote:

 Can I change pin function after gpio was requested? In low-power state
 (i.e. when display is disabled) it's gpio driving some level,
 and in active state it's some LCD controller pin (don't remember which
 one exactly)

Please read the section named GPIO mode pitfalls in
Documentation/pinctrl.txt very closely.

Two ways:

- You can use the GPIO and pin control interface to the same
  hardware in parallel. There is no blocking this since there
  is hardware out that that actually allow this. NOT
  RECOMMENDED.

- If the GPIO mode mentioned is only about e.g. grounding
  the pins in a low power state and then not really about using
  them as GPIO, extend the pin controller to be able to e.g.
  ground the pins with PIN_CONFIG_OUTPUT or
  PIN_CONFIG_LOW_POWER_MODE if you use
  generic bindings.

If the usecase is low power, the latter approach is recommended.

Yours,
Linus Walleij
--
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/2] pinctrl: exynos: Add BUS1 pin controller for exynos7

2014-12-03 Thread Linus Walleij
On Mon, Dec 1, 2014 at 3:21 PM, Vivek Gautam gautamvivek1...@gmail.com wrote:
 On Fri, Nov 28, 2014 at 9:15 PM, Linus Walleij linus.wall...@linaro.org 
 wrote:

 Apart from that, there are *again* a lot of Exynos patches flying around and
 I start to loose track of them. If they do not apply together and start to
 conflict I will just ask Tomasz to stack them and provide a pull request
 again.

 True, this merge cycle has surely got number of exynos7 related
 patches in flight,
 which are difficult to keep track of.
 Thanks for asking Tomasz.

I will probably not take any more Exynos patches for this merge cycle and
ask Tomasz to queue the Exynos pinctrl patches for v3.20 after v3.19
merge cycle is complete, so make sure to include Tomasz on reviews.

Tomasz: OK?

Yours,
Linus Walleij
--
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 3/5] pinctrl: exynos: add exynos5410 SoC specific data

2014-11-28 Thread Linus Walleij
On Sat, Nov 22, 2014 at 11:26 PM, Andreas Färber afaer...@suse.de wrote:

 From: Hakjoo Kim ruppi@hardkernel.com

 Add Samsung EXYNOS5410 SoC specific data to enable pinctrl
 support for all platforms based on EXYNOS5410.

 Signed-off-by: Hakjoo Kim ruppi@hardkernel.com
 [AF: Rebased onto Exynos5260 and irq_chip consolidation]
 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  v2 - v3:
  * Rebased (.svc, .{g,w}eint_{con,mask,pend} fields dropped)

  v1 - v2:
  * Filled in Sob from Hakjoo Kim

Is this based on the pinctrl devel branch so I can apply it?

I'd like Tomasz ACK on it first though.

Yours,
Linus Walleij
--
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] pinctrl: exynos: Fix GPIO setup failure because domain clock being gated

2014-11-28 Thread Linus Walleij
On Wed, Nov 26, 2014 at 3:24 PM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:

 The audio subsystem on Exynos 5420 has separate clocks and GPIO. To
 operate properly on GPIOs the main block clock 'mau_epll' must be
 enabled.

 This was observed on Peach Pi/Pit and Arndale Octa (after enabling i2s0)
 after introducing runtime PM to pl330 DMA driver. After that commit the
 'mau_epll' was gated, because the amba clock was disabled and there
 were no more users of mau_epll.

 The system hang just before probing i2s0 because
 samsung_pinmux_setup() tried to access memory from audss block which was
 gated.

 Add a clock property to the pinctrl driver and enable the clock during
 GPIO setup. During normal GPIO operations (set, get, set_direction) the
 clock is not enabled.

 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com

Waiting for Tomasz to review this.

Can this patch be applied in separation from the others?

Yours,
Linus Walleij
--
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/2] pinctrl: exynos: Add BUS1 pin controller for exynos7

2014-11-28 Thread Linus Walleij
On Fri, Nov 28, 2014 at 4:39 AM, Vivek Gautam gautamvivek1...@gmail.com wrote:
 On Fri, Nov 28, 2014 at 9:05 AM, Vivek Gautam gautamvivek1...@gmail.com 
 wrote:

 On Mon, Nov 24, 2014 at 6:32 PM, Vivek Gautam gautam.vi...@samsung.com 
 wrote:
 USB and Power regulator on Exynos7 require gpios available
 in BUS1 pin controller block.
 So adding the BUS1 pinctrl support.

 Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Linus Walleij linus.wall...@linaro.org

 If the change looks good, will it be possible to pick it fo 3.19-rc1 ?
 That will really help enabling USB IP on exynos7.

As you know the Exynos driver has a maintainer, Tomasz Figa, I will not
merge patches without his ACK.

Apart from that, there are *again* a lot of Exynos patches flying around and
I start to loose track of them. If they do not apply together and start to
conflict I will just ask Tomasz to stack them and provide a pull request
again.

Yours,
Linus Walleij
--
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: Samsung pinctrl patches for v3.19

2014-11-10 Thread Linus Walleij
On Sun, Nov 9, 2014 at 3:25 PM, Tomasz Figa tomasz.f...@gmail.com wrote:

 Please consider the following pull request containing queued changes for
 pinctrl-samsung driver.

Thanks, pulled!

 I'm sorry for all the delays in handling this. Things
 should get better from now on, though.

IIUC you are a hobbyist maintainer now, and then I will tolerate a
*lot* more than this, that is one of the privileges that comes with
that role, haha :D

Yours,
Linus Walleij
--
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 0/6] Add initial support for pinctrl on Exynos7

2014-10-28 Thread Linus Walleij
On Fri, Oct 24, 2014 at 4:33 PM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
 On Fri, Oct 24, 2014 at 5:31 PM, Linus Walleij linus.wall...@linaro.org 
 wrote:
 On Mon, Oct 20, 2014 at 4:01 PM, Abhilash Kesavan
 kesavan.abhil...@gmail.com wrote:

 Can you please pick this series up.

 Yes, sorry for the delay. I've applied patches
 1,2,3,4. The patches to the DTS files should be taken
 through whatever tree funnels arm64 dts files.

 Thank you for applying my patches. However, this version (v5) was
 based on Tomasz's clean-up series (...)

And Tomasz series had other problems.

So now I took everything out and asked Tomasz to get
a pull request for the stuff instead.

Yours,
Linus Walleij
--
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 0/6] Add initial support for pinctrl on Exynos7

2014-10-24 Thread Linus Walleij
On Mon, Oct 20, 2014 at 4:01 PM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:

 Can you please pick this series up.

Yes, sorry for the delay. I've applied patches
1,2,3,4. The patches to the DTS files should be taken
through whatever tree funnels arm64 dts files.

I hope Tomasz can rebase his nice
clean-up patches on top of this now.

Yours,
Linus Walleij
--
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] pinctrl: samsung: Data structure clean-up

2014-10-24 Thread Linus Walleij
On Wed, Oct 8, 2014 at 12:23 PM, Linus Walleij linus.wall...@linaro.org wrote:
 On Thu, Oct 2, 2014 at 8:52 PM, Tomasz Figa tomasz.f...@gmail.com wrote:

 This series intends to clean up data structures used by pinctrl-samsung 
 driver.
 More specifically, it separates initial compile time constants from data used
 at runtime, allowing unused variant data to be dropped and selected 
 structures
 constified to improve safety.

 Thanks!

 The patches missed the v3.18 merge window, but I have queued them up as
 the first thing to go into v3.19.

I wrote somewhere else that this exploded somehow.

I've merged Abhilash's patches so now this work needs to be rebased
on top of his stuf...


Yours,
Linus Walleij
--
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 v4 0/6] Add initial support for pinctrl on Exynos7

2014-10-08 Thread Linus Walleij
On Mon, Oct 6, 2014 at 5:42 AM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
 On Tue, Sep 30, 2014 at 8:00 PM, Abhilash Kesavan a.kesa...@samsung.com 
 wrote:
 Changes since v3:
 - Changed variable name from exynos_wkup_irq_chip to irq_chip
 - Added acked-by tag from Tomasz Figa

 Changes since v2:
 - Added a .irq_chip field to the samsung_pin_bank struct
 - Consolidated the wakeup and gpio irqd_ops

 Changes since v1:
 - Marked the newly created irq_chip instances as __initdata
 - Used kmemdup to keep a copy of the irq_chip
 - Change the pinctrl name from sd0_rdqs to sd0_ds as per UM
 - Moved the pinctrl enablement for exynos7 into a separate patch
 - Added tested-by and reviewed-by tags from Thomas Abraham

OK...

 Does this series look OK to you ?

I'm waiting for review comments form Tomasz Figa.

I have just applied his 5 refactoring patches as the first base
for v3.19, I don't know if this stuff will fit nicely on top of these
or not, expect to find out during review. Tomasz patches have
priority since they have been in-flight for a while and he is listed
as maintainer for this driver.

So could you make sure to get Tomasz review tag and make
sure that these patches work on top of his patches? His
patches are on my devel branch in the pin control tree, but
will not be pushed to linux-next until the merge window ends.

Yours,
Linus Walleij
--
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] pinctrl: samsung: Data structure clean-up

2014-10-08 Thread Linus Walleij
On Thu, Oct 2, 2014 at 8:52 PM, Tomasz Figa tomasz.f...@gmail.com wrote:

 This series intends to clean up data structures used by pinctrl-samsung 
 driver.
 More specifically, it separates initial compile time constants from data used
 at runtime, allowing unused variant data to be dropped and selected structures
 constified to improve safety.

Thanks!

The patches missed the v3.18 merge window, but I have queued them up as
the first thing to go into v3.19.

Now I need you to help me check the patch set from Abhilash so I know
what to do about that, whenever you have some time...

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/5] pinctrl: samsung: Data structure clean-up

2014-10-02 Thread Linus Walleij
On Sat, Sep 27, 2014 at 2:50 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
 On 25.09.2014 09:49, Tomasz Figa wrote:
 On 25.09.2014 09:47, Linus Walleij wrote:
 On Tue, Sep 23, 2014 at 9:05 PM, Tomasz Figa tomasz.f...@gmail.com wrote:

 This series intends to clean up data structures used by pinctrl-samsung 
 driver.
 More specifically, it separates initial compile time constants from data 
 used
 at runtime, allowing unused variant data to be dropped and selected 
 structures
 constified to improve safety.

 I like the patch set, tried to apply it but patch 3/5 failed to apply to the
 devel branch for pinctrl.

 Can you rebase this on my devel branch, include Marek's Tested-by
 tag and resend, and I'll take it for v3.18.

 Sure. Will do that today evening. Probably clashed with some other
 changes queued in the meantime.

 Uhm. I went back home and forgot about this series until now. Sorry.

 I have rebased it on your devel branch, although it seems like this
 branch is missing [1], which in turn seems to be already present in your
 for-next branch and is going to cause a merge conflict with this
 series. Should I still proceed with posting the series based on devel?

 [1] f6a8249f9e55d pinctrl: exynos: Lock GPIOs as interrupts when used as
 EINTs

Bah I must have accidentally applied the patch to my for-next
branch instead of devel, and then wiped it out of existence when
I later reset the for-next branch to devel.

Please resend all 5 rebased on devel.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/5] pinctrl: samsung: Data structure clean-up

2014-09-25 Thread Linus Walleij
On Tue, Sep 23, 2014 at 9:05 PM, Tomasz Figa tomasz.f...@gmail.com wrote:

 This series intends to clean up data structures used by pinctrl-samsung 
 driver.
 More specifically, it separates initial compile time constants from data used
 at runtime, allowing unused variant data to be dropped and selected structures
 constified to improve safety.

I like the patch set, tried to apply it but patch 3/5 failed to apply to the
devel branch for pinctrl.

Can you rebase this on my devel branch, include Marek's Tested-by
tag and resend, and I'll take it for v3.18.

Yours,
Linus Walleij
--
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] kbuild: remove unnecessary variable initializaions

2014-09-23 Thread Linus Walleij
On Tue, Sep 9, 2014 at 12:26 PM, Masahiro Yamada
yamad...@jp.panasonic.com wrote:

 Clearing obj-y, obj-m, obj-n, obj- in each Makefile is
 a useless habit.

 They are non-exported variables; therefore they are always empty
 whenever descending into each subdirectory.
 (Moreorver, obj-y and obj-m are also set to empty at the beginning
 of scripts/Makefile.build)

 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

Acked-by: Linus Walleij linus.wall...@linaro.org

Yours,
Linus Walleij
--
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] pinctrl: exynos: Generalize the eint16_31 demux code

2014-09-23 Thread Linus Walleij
On Tue, Sep 23, 2014 at 10:16 AM, Abhilash Kesavan
a.kesa...@samsung.com wrote:

 The function exynos_irq_demux_eint16_31 uses pre-defined offsets for external
 interrupt pending status and mask registers. So this function is not 
 extensible
 for Exynos7 SoC which have these registers at different offsets. So generalize
 the exynos_irq_demux_eint16_31 function by using the pending/mask register
 offset values from the exynos_irq_chip structure.

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 Reviewed-by: Thomas Abraham thomas...@samsung.com
 Tested-by: Thomas Abraham thomas...@samsung.com
 Cc: Thomas Abraham thomas...@samsung.com
 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: Linus Walleij linus.wall...@linaro.org

I'm waiting for the maintainers to ACK these patches
before I take them.

Yours,
Linus Walleij
--
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] MAINTAINERS: Tomasz has moved

2014-08-29 Thread Linus Walleij
On Tue, Aug 26, 2014 at 4:30 PM, Tomasz Figa t.f...@samsung.com wrote:

 I am leaving Samsung, so my current e-mail address is not going to work
 any longer. Replace it with my private one. In addition, Sylwester
 Nawrocki is being added as co-maintainer for Samsung clock drivers to
 take some of the responsibilities, as I will be doing my part in my spare
 time.

 Signed-off-by: Tomasz Figa t.f...@samsung.com

OK I'm taking this patch through pinctrl fixes. Not much controversy
here, Mike you need not worry about it.

Patch applied.

Yours,
Linus Walleij
--
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 06/14] pinctrl: samsung: use CONFIG_PINCTRL_SAMSUNG symbol in makefile

2014-08-29 Thread Linus Walleij
On Wed, Aug 27, 2014 at 11:48 AM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:

 Samsung Exynos7 is a ARM64bit processor. Which does not select
 the CONFIG_PLAT_SAMSUNG symbol. CONFIG_PINCTRL_SAMSUNG is being
 selected for both PLAT_SAMSUNG and ARCH_EXYNOS7 symbols.

 This patch modifes the pinctrl/Makefile to use
 CONFIG_PINCTRL_SAMSUNG symbol to compile the pinctrl/samsung/*.c

 Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
 Cc: Tomasz Figa t.f...@samsung.com
 Cc: linus.wall...@linaro.org
 Cc: Thomas Abraham thomas...@samsung.com

Excellent catch, thanks, patch applied!

I should use this pattern on more places in the Makefile,
I was confused by logically thinking that Kconfig symbols
used in Makefile cannot be from a Kconfig one level below.

Yours,
Linus Walleij
--
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] pinctrl: exynos: Lock GPIOs as interrupts when used as EINTs

2014-08-21 Thread Linus Walleij
On Fri, Aug 8, 2014 at 6:48 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:

 From: Tomasz Figa t.f...@samsung.com

 Currently after configuring a GPIO pin as an interrupt related pinmux
 registers are changed, but there is no protection from calling
 gpio_direction_*() in a badly written driver, which would cause the same
 pinmux register to be reconfigured for regular input/output and this
 disabling interrupt capability of the pin.

 This patch addresses this issue by moving pinmux reconfiguration to
 .irq_{request,release}_resources() callback of irq_chip and calling
 gpio_lock_as_irq() helper to prevent reconfiguration of pin direction.

 Setting up a GPIO interrupt on Samsung SoCs is a two-step operation -
 in addition to trigger configuration in a dedicated register, the pinmux
 must be also reconfigured to GPIO interrupt, which is a different function
 than normal GPIO input, although I/O-wise they both behave in the same way
 and gpio_get_value() can be used on a pin configured as IRQ as well.

 Such design implies subtleties such as gpio_direction_input() not having
 to fail if a pin is already configured as an interrupt nor change the
 configuration to normal input. But the FLAG_USED_AS_IRQ set in gpiolib by
 gpio_lock_as_irq() is only used to check that gpio_direction_output() is
 not called, it's not used to prevent gpio_direction_input() to be called.
 So this is not a complete solution for Samsung SoCs but it's definitely a
 move in the right direction.

 Signed-off-by: Tomasz Figa t.f...@samsung.com
 [javier: use request resources instead of startup and expand commit message]
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

OK patch applied for fixes, sorry for missing to follow up on this.

Yours,
Linus Walleij
--
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

2014-08-11 Thread Linus Walleij
I guess this discussion is about drivers/pinctrl/samsung/pinctrl-exynos.c?

Or else I'm not really following this... $SUBJECT is a bit confusing.

On Sat, Aug 9, 2014 at 12:26 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:

 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.

I think someone should look into switching the Samsung/Exynos pinctrl
driver to the gpiolib irqchip helpers, I looked at it but was scared by
the special wkup chip and stuff I can't test.

The irqchip helpers will atleast help out in flagging GPIO lines as
used for IRQs so the core can keep track of stuff and show that
properly in debugfs.

The orthogonality compliance between GPIO and irqchip must
however be solved in the driver itself, the core only helps out
in blocking some abuse of the API.

Yours,
Linus Walleij
--
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] pinctrl: exynos: Lock GPIOs as interrupts when used as EINTs

2014-08-11 Thread Linus Walleij
On Sat, Aug 9, 2014 at 1:48 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:

 From: Tomasz Figa t.f...@samsung.com

 Currently after configuring a GPIO pin as an interrupt related pinmux
 registers are changed, but there is no protection from calling
 gpio_direction_*() in a badly written driver, which would cause the same
 pinmux register to be reconfigured for regular input/output and this
 disabling interrupt capability of the pin.

 This patch addresses this issue by moving pinmux reconfiguration to
 .irq_{request,release}_resources() callback of irq_chip and calling
 gpio_lock_as_irq() helper to prevent reconfiguration of pin direction.

 Setting up a GPIO interrupt on Samsung SoCs is a two-step operation -
 in addition to trigger configuration in a dedicated register, the pinmux
 must be also reconfigured to GPIO interrupt, which is a different function
 than normal GPIO input, although I/O-wise they both behave in the same way
 and gpio_get_value() can be used on a pin configured as IRQ as well.

 Such design implies subtleties such as gpio_direction_input() not having
 to fail if a pin is already configured as an interrupt nor change the
 configuration to normal input. But the FLAG_USED_AS_IRQ set in gpiolib by
 gpio_lock_as_irq() is only used to check that gpio_direction_output() is
 not called, it's not used to prevent gpio_direction_input() to be called.
 So this is not a complete solution for Samsung SoCs but it's definitely a
 move in the right direction.

 Signed-off-by: Tomasz Figa t.f...@samsung.com
 [javier: use request resources instead of startup and expand commit message]
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---

 This patch solves the issue explained in https://lkml.org/lkml/2014/8/8/461

Hm, this looks much better atleast, it is not possible to use the
irqchip helpers from gpiolib then, because that grabs the request/release
resource callbacks.

If I get some ACKs on this we can go for this solution.

Yours,
Linus Walleij
--
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 3/5] pinctrl: exynos: add exynos5410 SoC specific data

2014-08-08 Thread Linus Walleij
On Mon, Jul 28, 2014 at 2:18 PM, Andreas Färber afaer...@suse.de wrote:

 From: Hakjoo Kim ruppi@hardkernel.com

 Add Samsung EXYNOS5410 SoC specific data to enable pinctrl
 support for all platforms based on EXYNOS5410.

 Cc: Hakjoo Kim ruppi@hardkernel.com
 [AF: Rebased onto Exynos5260]

I'm waiting for Tomasz to review this before applying.

Yours,
Linus Walleij
--
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/24] mfd: max77686: Add Dynamic Voltage Scaling (DVS) support

2014-07-10 Thread Linus Walleij
On Fri, Jul 4, 2014 at 10:24 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:

 Some regulators on the MAX77686 PMIC have Dynamic Voltage Scaling
 (DVS) support that allows output voltage to change dynamically.

 For MAX77686, these regulators are Buck regulators 2, 3 and 4.

 Each Buck output voltage is selected using a set of external
 inputs: DVS1-3 and SELB2-4.

 DVS registers can be used to configure the output voltages for each
 Buck regulator and which one is active is controled by DVSx lines.

 SELBx lines are used to control if individual Buck lines are ON or OFF.

 This patch adds support to configure the DVSx and SELBx lines
 from DT and to setup and read the GPIO lines connected to them.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com

(...)
 +#include linux/gpio/consumer.h

THANKS for using modern interfaces!

 +static void max77686_dt_parse_dvs_gpio(struct device *dev)
 +{
 +   struct max77686_platform_data *pd = dev_get_platdata(dev);
 +   int i;
 +
 +   /*
 +* NOTE: we don't consider GPIO errors fatal; board may have some 
 lines
 +* directly pulled high or low and thus doesn't specify them.
 +*/
 +   for (i = 0; i  ARRAY_SIZE(pd-buck_gpio_dvs); i++)
 +   pd-buck_gpio_dvs[i] =
 +   devm_gpiod_get_index(dev, max77686,pmic-buck-dvs, 
 i);
 +
 +   for (i = 0; i  ARRAY_SIZE(pd-buck_gpio_selb); i++)
 +   pd-buck_gpio_selb[i] =
 +   devm_gpiod_get_index(dev, max77686,pmic-buck-selb, 
 i);
 +}

Rob Jones has a patch cooking that adds gpio_get_array() so this thing
merits also adding devm_gpiod_get_array() I think?

 +/**
 + * max77686_setup_gpios() - init DVS-related GPIOs
 + * @dev: device whose platform data contains the dvs GPIOs information
 + *
 + * This function claims / initalizations GPIOs related to DVS if they are
 + * defined. This may have the effect of switching voltages if the
 + * pdata-buck_default_idx does not match the boot time state of pins.
 + */
 +int max77686_setup_gpios(struct device *dev)
 +{
 +   struct max77686_platform_data *pd = dev_get_platdata(dev);
 +   int buck_default_idx = pd-buck_default_idx;
 +   int ret;
 +   int i;
 +
 +   /* Set all SELB high to avoid glitching while DVS is changing */
 +   for (i = 0; i  ARRAY_SIZE(pd-buck_gpio_selb); i++) {
 +   struct gpio_desc *gpio = pd-buck_gpio_selb[i];
 +
 +   /* OK if some GPIOs aren't defined */
 +   if (IS_ERR(gpio))
 +   continue;
 +
 +   ret = gpiod_direction_output_raw(gpio, 1);

Why does this have to be raw? Usually that is not to be used.

Apart from this it looks OK.

Yours,
Linus Walleij
--
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] pinctrl: samsung: Group all drivers in a sub-dir

2014-07-10 Thread Linus Walleij
On Thu, Jul 10, 2014 at 2:03 PM, Sachin Kamat sachin.ka...@samsung.com wrote:

 Group all pin control drivers of Samsung platform together in
 a sub-directory for easy maintenance.

 Signed-off-by: Sachin Kamat sachin.ka...@samsung.com

Patch applied.

Yours,
Linus Walleij
--
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] pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes

2014-07-09 Thread Linus Walleij
On Wed, Jul 2, 2014 at 5:41 PM, Tomasz Figa t.f...@samsung.com wrote:

 One of remaining limitations of current pinctrl-samsung driver was
 the inability to parse multiple pinmux/pinconf group nodes grouped
 inside a single device tree node. It made defining groups of pins for
 single purpose, but with different parameters very inconvenient.

 This patch implements Tegra-like support for grouping multiple pinctrl
 groups inside one device tree node, by completely changing the way
 pin groups and functions are parsed from device tree. The code creating
 pinctrl maps from DT nodes has been borrowed from pinctrl-tegra, while
 the initial creation of groups and functions has been completely
 rewritten with following assumptions:
  - each group consists of just one pin and does not depend on data
from device tree,
  - each function is represented by a device tree child node of the
pin controller, which in turn can contain multiple child nodes
for pins that need to have different configuration values.

 Device Tree bindings are fully backwards compatible. New functionality
 can be used by defining a new pinctrl group consisting of several child
 nodes, as on following example:

 sd4_bus8: sd4-bus-width8 {
 part-1 {
 samsung,pins = gpk0-3, gpk0-4,
 gpk0-5, gpk0-6;
 samsung,pin-function = 3;
 samsung,pin-pud = 3;
 samsung,pin-drv = 3;
 };
 part-2 {
 samsung,pins = gpk1-3, gpk1-4,
 gpk1-5, gpk1-6;
 samsung,pin-function = 4;
 samsung,pin-pud = 4;
 samsung,pin-drv = 3;
 };
 };

 Tested on Exynos4210-Trats board and a custom Exynos4212-based one.

 Signed-off-by: Tomasz Figa t.f...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 Reviewed-by: Stephen Warren swar...@nvidia.com
 Cc: devicet...@vger.kernel.org
 Cc: Rob Herring robh...@kernel.org
 Cc: Mark Rutland mark.rutl...@arm.com

Patch applied.

(This decision is mainly based on trust, I got lost in the patch :-)

Yours,
Linus Walleij
--
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 6/6] pinctrl: samsung: Allow pin value to be initialized using pinfunc

2014-07-09 Thread Linus Walleij
On Wed, Jul 2, 2014 at 5:41 PM, Tomasz Figa t.f...@samsung.com 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, which is useful for pins that are not supposed to be used by
 any dedicated driver, but need certain board-specific setting.

 Signed-off-by: Tomasz Figa t.f...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com

Patch applied. It always makes me a little bit sad that we didn't get
generic pin config in place before this driver but now we have to live
with it.

Yours,
Linus Walleij
--
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 mask-tpm-reset to the device tree

2014-07-08 Thread Linus Walleij
On Thu, Jun 26, 2014 at 11:15 AM, Vikas Sajjan vikas.saj...@samsung.com wrote:

 From: Doug Anderson diand...@chromium.org

 The mask-tpm-reset GPIO is used by the kernel to prevent the TPM from
 being reset across sleep/wake.  If we don't set it to anything then
 the TPM will be reset.  U-Boot will detect this as invalid
 and will reset the system on resume time. This GPIO can always be low
 and not hurt anything.  It will get pulled back high again during a
 normal warm reset when it will default back to an input.

 To properly preserve the TPM state across suspend/resume and to make
 the chrome U-Boot happy, properly set the GPIO to mask the
 reset to the TPM.

 Signed-off-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
(...)
 +   /* We need GPX0_6 to be low at sleep time; just keep it low always */
 +   mask_tpm_reset_regulator: mask-tpm-reset-regulator {
 +   compatible = regulator-fixed;

No matter how the discussion ends up, regulator-fixed is wrong.

Either folding it into the TPM driver or using a separate reset driver
is fine with me.

So what about the generic delayed reset GPIO thing?
http://marc.info/?l=linux-kernelm=140309916607115w=2

Yours,
Linus Walleij
--
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 v3] reset: Add a defer reset object to send board specific reset

2014-07-08 Thread Linus Walleij
On Wed, Jun 18, 2014 at 3:37 PM, Houcheng Lin houch...@gmail.com wrote:

 The Problem
 ---
 The reset signal on a hardware board is send either:
 - during machine initialization
 - during bus master's initialization

I just thought about this a bit, since there isn't already a generic GPIO
reset driver, just call this drivers/reset/reset-gpio.c and make the
ability to deferral just a configuration detail of the GPIO reset driver.

Yours,
Linus Walleij
--
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] pinctrl: samsung: Decouple direction setting from pinctrl

2014-07-08 Thread Linus Walleij
On Wed, Jul 2, 2014 at 5:40 PM, Tomasz Figa t.f...@samsung.com wrote:

 This patch makes the pinctrl-samsung driver configure GPIO direction on
 its own, without using the pinctrl_gpio_direction_*() helpers. The
 rationale behind this change is as follows:
  - pinctrl-samsung does not need translation from GPIO namespace to
pinctrl namespace to handle GPIO operations - GPIO chip and offset
therein are enough to calculate necessary offsets and bit masks in
constant time,
  - the pinctrl_gpio_direction_*() functions do not do anything useful
other than translating the pin into pinctrl namespace and calling the
.gpio_set_direction() from pinmux_ops of the controller,
  - the undesirable side effect of using those helpers is losing the
ability to change GPIO direction in atomic context, because they
explicitly use a mutex for synchronization,

 Results of this patch are:
  - fixed warnings about scheduling while atomic in code that needs to
set GPIO direction in atomic context (e.g. interrupt handler),
  - reduced overhead of bitbanging drivers that use gpio_direction_*(),
e.g. i2c-gpio.

 Signed-off-by: Tomasz Figa t.f...@samsung.com

Well the cross-call function is actually mostly for the case when
the pinctrl and GPIO drivers are in different files, or you combine
two IP blocks arbitrarily. It's a bit messy anyway.

Patch applied.

Yours,
Linus Walleij
--
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] pinctrl: samsung: Handle GPIO request and free using pinctrl helpers

2014-07-08 Thread Linus Walleij
On Wed, Jul 2, 2014 at 5:41 PM, Tomasz Figa t.f...@samsung.com wrote:

 This patch adds .request() and .free() operations to gpio_chip of
 pinctrl-samsung driver, which call pinctrl request and free helpers to
 request and free pinctrl pin along with GPIO pin.

 Signed-off-by: Tomasz Figa t.f...@samsung.com

Patch applied.

Yours,
Linus Walleij
--
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] pinctrl: exynos: Consolidate irq_chips of GPIO and WKUP EINTs

2014-07-08 Thread Linus Walleij
On Wed, Jul 2, 2014 at 5:41 PM, Tomasz Figa t.f...@samsung.com wrote:

 Handling of irq_chip operations for GPIO and WKUP external interrupts
 is mostly the same, with the difference being offset of registers.
 However currently the driver has all the code duplicated for both EINT
 types, which is undesirable, because changes in irq_chip operations have
 to be done to both instances of the same code.

 This patch fixes this by creating exynos_irq_chip struct that has normal
 irq_chip struct embedded and contain differences between particular EINT
 types, which are three register offsets. One instance of code is removed
 and the new structure is used instead to fetch necessary data instead of
 samsung_pin_ctrl struct used previously.

 While at it, the patch removes Exynos-specific fields from
 aforementioned structure to improve layering of the driver.

 Signed-off-by: Tomasz Figa t.f...@samsung.com

Patch applied.

Yours,
Linus Walleij
--
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 4/6] pinctrl: exynos: Lock GPIOs as interrupts when used as EINTs

2014-07-08 Thread Linus Walleij
On Wed, Jul 2, 2014 at 5:41 PM, Tomasz Figa t.f...@samsung.com wrote:

 Currently after configuring a GPIO pin as an interrupt related pinmux
 registers are changed, but there is no protection from calling
 gpio_direction_*() in a badly written driver, which would cause the same
 pinmux register to be reconfigured for regular input/output and this
 disabling interrupt capability of the pin.

 This patch addresses this issue by moving pinmux reconfiguration to
 .irq_startup() callback of irq_chip and calling gpio_lock_as_irq()
 helper to prevent reconfiguration of pin direction.

 Signed-off-by: Tomasz Figa t.f...@samsung.com
(...)
 +   .irq_startup = exynos_irq_startup,
 +   .irq_shutdown = exynos_irq_shutdown,

I think you should be using the
.irq_request_resources and .irq_release_resources callbacks instead.

The reason is that startup and shutdown cannot really fail (ret code
is unsigned...), so using the other callbacks is safer.

Can you have a quick look at this before I apply any more of the
Samsung patches?

Yours,
Linus Walleij
--
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 v3] reset: Add a defer reset object to send board specific reset

2014-07-08 Thread Linus Walleij
On Tue, Jul 8, 2014 at 10:05 AM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
 On Tue, Jul 08, 2014 at 09:52:03AM +0200, Linus Walleij wrote:
 On Wed, Jun 18, 2014 at 3:37 PM, Houcheng Lin houch...@gmail.com wrote:

  The Problem
  ---
  The reset signal on a hardware board is send either:
  - during machine initialization
  - during bus master's initialization

 I just thought about this a bit, since there isn't already a generic GPIO
 reset driver, just call this drivers/reset/reset-gpio.c and make the
 ability to deferral just a configuration detail of the GPIO reset driver.

 Philipp has been working on one for quite some time. See
 http://www.spinics.net/lists/arm-kernel/msg321927.html

 However, it seems to progress slowly, and we don't seem to be able to
 reach a consensus here.

 If you ask me, having to set a few extra properties like this just
 advocates for a regular reset driver and DT node for the reset GPIO,
 but I'm pretty sure Philipp will feel otherwise :)

Hm haha yeah let's fight it out :-)

This is not my subsystem so I'm getting some popcorn.

Yours,
Linus Walleij
--
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 02/17] gpio: samsung: remove s5p64x0 related gpio codes

2014-07-07 Thread Linus Walleij
On Mon, Jun 30, 2014 at 11:32 PM, Kukjin Kim kgene@samsung.com wrote:

 This patch removes gpio codes for s5p6440 and s5p6450 SoCs.

 Signed-off-by: Kukjin Kim kgene@samsung.com
 Cc: Linus Walleij linus.wall...@linaro.org

Acked-by: Linus Walleij linus.wall...@linaro.org

Yours,
Linus Walleij
--
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 09/17] gpio: samsung: remov s5pc100 related gpio codes

2014-07-07 Thread Linus Walleij
On Mon, Jun 30, 2014 at 11:32 PM, Kukjin Kim kgene@samsung.com wrote:

 This patch removes gpio codes for s5pc100 SoC.

 Signed-off-by: Kukjin Kim kgene@samsung.com
 Cc: Linus Walleij linus.wall...@linaro.org

Acked-by: Linus Walleij linus.wall...@linaro.org

Yours,
Linus Walleij
--
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/6] ARM: mm: cache-l2x0: Add base address argument to write_sec callback

2014-06-27 Thread Linus Walleij
On Wed, Jun 25, 2014 at 3:37 PM, Tomasz Figa t.f...@samsung.com wrote:

 For certain platforms (e.g. Exynos) it is necessary to read back some
 values from registers before they can be written (i.e. SMC calls that
 set multiple registers per call), so base address of L2C controller is
 needed for .write_sec operation. This patch adds base argument to
 .write_sec callback so that its implementation can also access registers
 directly.

 Signed-off-by: Tomasz Figa t.f...@samsung.com

  arch/arm/mach-ux500/cache-l2x0.c   | 3 ++-

In our case just changing the signature of the function I see so:
Acked-by: Linus Walleij linus.wall...@linaro.org

Yours,
Linus Walleij
--
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: [PATCHv2] pinctrl: exynos: Add driver data for Exynos3250

2014-04-23 Thread Linus Walleij
On Mon, Apr 14, 2014 at 3:45 AM, Chanwoo Choi cw00.c...@samsung.com wrote:

 From: Tomasz Figa t.f...@samsung.com

 This patch adds driver data (bank list and EINT layout) for Exynos3250
 to pinctrl-exynos driver. Exynos3250 includes 158 multi-functional 
 input/output
 ports. There are 23 general port groups.

 Changes from v1:
 - Add signed-off of sender
 - Post only separated patch for pinctrl from following patchset(v1)
   : https://lkml.org/lkml/2014/4/10/286

 Cc: Thomas Abraham thomas.abra...@linaro.org
 Cc: Linus Walleij linus.wall...@linaro.org
 Cc: Kukjin Kim kgene@samsung.com
 Signed-off-by: Tomasz Figa t.f...@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com

This v2 patch applied.

Yours,
Linus Walleij
--
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 08/27] pinctrl: exynos: Add driver data for Exynos3250

2014-04-10 Thread Linus Walleij
On Thu, Apr 10, 2014 at 11:28 AM, Chanwoo Choi cw00.c...@samsung.com wrote:

 From: Tomasz Figa t.f...@samsung.com

 This patch adds driver data (bank list and EINT layout) for Exynos3250
 to pinctrl-exynos driver. Exynos3250 includes 158 multi-functional 
 input/output
 ports. There are 23 general port groups.

 Signed-off-by: Tomasz Figa t.f...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

Ugh can Tomasz send out his patches himself, I get confused...
It was also sent two times, the second time with CC:s added.
Tomasz, shall I merge this?

Yours,
Linus Walleij
--
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 49/75] ARM: l2c: fix register naming

2014-03-28 Thread Linus Walleij
On Fri, Mar 28, 2014 at 4:18 PM, Russell King
rmk+ker...@arm.linux.org.uk wrote:

 We have a mixture of different devices with different register layouts,
 but we group all the bits together in an opaque mess.  Split them out
 into those which are L2C-310 specific and ones which refer to earlier
 devices.  Provide full auxiliary control register definitions.

 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk

Acked-by: Linus Walleij linus.wall...@linaro.org
For ux500.

Yours,
Linus Walleij
--
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] pinctrl: exynos: add exynos5260 SoC specific data

2014-02-06 Thread Linus Walleij
On Wed, Feb 5, 2014 at 7:21 AM, Rahul Sharma rahul.sha...@samsung.com wrote:

 From: Young-Gun Jang yg1004.j...@samsung.com

 Adds pinctrl support for all platforms based on EXYNOS5260 SoC.

 Acked-by: Tomasz Figa t.f...@samsung.com
 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 Signed-off-by: Arun Kumar K arun...@samsung.com

Patch applied.

Yours,
Linus Walleij
--
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: S5P[v210|c100|64x0]: Fix build error

2014-01-15 Thread Linus Walleij
On Wed, Jan 15, 2014 at 10:01 AM, Sachin Kamat sachin.ka...@linaro.org wrote:

 gpio-samsung.h header file introduced by commit 93177be0910c
 (ARM: S3C[24|64]xx: move includes back under mach/ scope)
 is required only by S3C[24|64]xx machines. Include them conditionally
 to avoid the following build errors for other machine configurations.
 drivers/gpio/gpio-samsung.c:35:31: fatal error: mach/gpio-samsung.h: No such 
 file or directory
 arch/arm/plat-samsung/pm-gpio.c:22:31: fatal error: mach/gpio-samsung.h: No 
 such file or directory

 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org

Damned I couldn't get rid of the ifdefs anyway :-(

Thanks Sachin, patch applied.

Yours,
Linus Walleij
--
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: S3C[24|64]xx: move includes back under mach/ scope

2014-01-15 Thread Linus Walleij
On Wed, Jan 15, 2014 at 10:43 AM, Arnd Bergmann a...@arndb.de wrote:
 On Wednesday 15 January 2014 14:41:01 Tushar Behera wrote:

 This inclusion should be protected by a check for CONFIG_ARCH_S3C24XX
 || CONFIG_ARCH_S3C64XX. Currently generating build errors for
 s5p64x0_defconfig, s5pc100_defconfig and s5pv210_defconfig on
 next-20140115.

 I noticed the same problem, but I think a better solution would
 be to do the same change for s5p that Linus has done for s3c,
 which is to move the nonstandard contents of mach/gpio.h to
 mach/gpio-samsung.h.

Hm I just applied a fixup from Sachin adding #ifdefs back in
but maybe I should try to fix it up like that instead. Just a minute...

Yours,
Linus Walleij
--
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: S3C[24|64]xx: move includes back under mach/ scope

2014-01-15 Thread Linus Walleij
On Wed, Jan 15, 2014 at 10:43 AM, Arnd Bergmann a...@arndb.de wrote:
 On Wednesday 15 January 2014 14:41:01 Tushar Behera wrote:
  diff --git a/arch/arm/plat-samsung/pm-gpio.c 
  b/arch/arm/plat-samsung/pm-gpio.c
  index c4efa1c2a5d1..a9f7a37c4173 100644
  --- a/arch/arm/plat-samsung/pm-gpio.c
  +++ b/arch/arm/plat-samsung/pm-gpio.c
  @@ -19,12 +19,7 @@
   #include linux/io.h
   #include linux/gpio.h
 
  -#ifdef CONFIG_ARCH_S3C24XX
  -#include linux/platform_data/gpio-samsung-s3c24xx.h
  -#endif
  -#ifdef CONFIG_ARCH_S3C64XX
  -#include linux/platform_data/gpio-samsung-s3c64xx.h
  -#endif
  +#include mach/gpio-samsung.h

 This inclusion should be protected by a check for CONFIG_ARCH_S3C24XX
 || CONFIG_ARCH_S3C64XX. Currently generating build errors for
 s5p64x0_defconfig, s5pc100_defconfig and s5pv210_defconfig on
 next-20140115.


 I noticed the same problem, but I think a better solution would
 be to do the same change for s5p that Linus has done for s3c,
 which is to move the nonstandard contents of mach/gpio.h to
 mach/gpio-samsung.h.

When I look at it, the issue also exist in e.g.
drivers/gpio/gpio-samsung.c which can be compiled
(like for allyesconfig) when PLAT_SAMSUNG is set.

And it is also set to y for ARCH_EXYNOS... which
doesn't have any custom GPIO header. So this would
involve something like creating an empty
mach/gpio-samsung.h for Exynos which doesn't
seem like the right thing to do.

So I'm sticking with the #ifdef patch for now as it
seems to be the lesser evil :-/

Yours,
Linus Walleij
--
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 v3] ARM: s3c24xx: get rid of custom mach/gpio.h

2014-01-14 Thread Linus Walleij
On Wed, Jan 8, 2014 at 4:59 PM, Arnd Bergmann a...@arndb.de wrote:

 I've asked the mighty grep and it said that these are the files
 using the contents you moved around:

 drivers/gpio/gpio-samsung.c
 drivers/leds/leds-s3c24xx.c
 drivers/mmc/host/s3cmci.c
 sound/soc/samsung/h1940_uda1380.c
 sound/soc/samsung/neo1973_wm8753.c
 sound/soc/samsung/rx1950_uda1380.c
 sound/soc/samsung/s3c2412-i2s.c
 sound/soc/samsung/s3c24xx-i2s.c
 sound/soc/samsung/smartq_wm8987.c

 The symbols used in these drivers are:

 S3CGP.()
 S3C_GPIO_END
 S3C_GPIO_PULL_.*
 S3C_GPIO_SFN()
 s3c_gpio_cfgall_range()
 s3c_gpio_setpull()

Hm I will look closer at these. Maybe I can even fix some to just
pass GPIO thru platform data and end-of-story them.
Targeting v3.15.

But I guess you want me to move the
linux/platform_data/gpio-s3c* back to mach/*
before v3.14 so focusing on that now. (These patches
cannot be just reverted as people have fixed other
Samsung GPIO issues on top of them, so it needs to be done
carefully.)

 I think it would be worthwhile to go ahead and make all inclusions of
 the plat/gpio-cfg.h file explicit, and remove it from mach/gpio.h, that
 part should be simple enough and helpful at the same time.

plat/gpio-cfg.h is used by S5P as well, but I guess you've
checked that.

If I take it driver-by-driver it should be possible to get rid of it
or most of it I think, reducing it to the arch/arm/mach-* folder.

Certainly I should be attacking S3C and S5P simultaneously.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ARM: s3c24xx: explicit dependency on plat/gpio-cfg.h

2014-01-14 Thread Linus Walleij
Previously the custom GPIO header for the S3C24xx would in turn
bring in the custom pin control implementation from
plat/gpio-cfg.h. This is not good as it mixes up two
subsystems and makes the dependencies hard to track. Make
the dependency explicit by explicitly including the pin
control header where needed.

Reported-by: Arnd Bergmann a...@arndb.de
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Sylwester Nawrocki sylvester.nawro...@gmail.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Heiko Stuebner he...@sntech.de
Cc: Mark Brown broo...@kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
Maintainers: this builds on top of the previous patch moving
headers back to mach/*. This will also boil in linux-next,
ACKs appreciated.
---
 arch/arm/mach-s3c24xx/h1940-bluetooth.c   | 1 +
 arch/arm/mach-s3c24xx/include/mach/gpio-samsung.h | 2 --
 arch/arm/mach-s3c24xx/mach-rx1950.c   | 1 +
 arch/arm/mach-s3c24xx/pm-s3c2410.c| 1 +
 arch/arm/mach-s3c24xx/setup-ts.c  | 1 +
 drivers/mmc/host/s3cmci.c | 1 +
 6 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/h1940-bluetooth.c 
b/arch/arm/mach-s3c24xx/h1940-bluetooth.c
index ff3afc163178..b4d14b864367 100644
--- a/arch/arm/mach-s3c24xx/h1940-bluetooth.c
+++ b/arch/arm/mach-s3c24xx/h1940-bluetooth.c
@@ -19,6 +19,7 @@
 #include linux/gpio.h
 #include linux/rfkill.h
 
+#include plat/gpio-cfg.h
 #include mach/hardware.h
 #include mach/regs-gpio.h
 #include mach/gpio-samsung.h
diff --git a/arch/arm/mach-s3c24xx/include/mach/gpio-samsung.h 
b/arch/arm/mach-s3c24xx/include/mach/gpio-samsung.h
index 79b3a0e44955..528fcdc4f63e 100644
--- a/arch/arm/mach-s3c24xx/include/mach/gpio-samsung.h
+++ b/arch/arm/mach-s3c24xx/include/mach/gpio-samsung.h
@@ -93,8 +93,6 @@ enum s3c_gpio_number {
 #define S3C2410_GPL(_nr)   (S3C2410_GPIO_L_START + (_nr))
 #define S3C2410_GPM(_nr)   (S3C2410_GPIO_M_START + (_nr))
 
-#include plat/gpio-cfg.h
-
 #ifdef CONFIG_CPU_S3C244X
 #define S3C_GPIO_END   (S3C2410_GPJ(0) + 32)
 #elif defined(CONFIG_CPU_S3C2443) || defined(CONFIG_CPU_S3C2416)
diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c 
b/arch/arm/mach-s3c24xx/mach-rx1950.c
index 345d01aa3524..0a5456cda1bc 100644
--- a/arch/arm/mach-s3c24xx/mach-rx1950.c
+++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
@@ -59,6 +59,7 @@
 #include plat/pm.h
 #include plat/regs-serial.h
 #include plat/samsung-time.h
+#include plat/gpio-cfg.h
 
 #include common.h
 #include h1940.h
diff --git a/arch/arm/mach-s3c24xx/pm-s3c2410.c 
b/arch/arm/mach-s3c24xx/pm-s3c2410.c
index 509b20b4ab3b..20e481d8a33a 100644
--- a/arch/arm/mach-s3c24xx/pm-s3c2410.c
+++ b/arch/arm/mach-s3c24xx/pm-s3c2410.c
@@ -35,6 +35,7 @@
 #include mach/regs-gpio.h
 #include mach/gpio-samsung.h
 
+#include plat/gpio-cfg.h
 #include plat/cpu.h
 #include plat/pm.h
 
diff --git a/arch/arm/mach-s3c24xx/setup-ts.c b/arch/arm/mach-s3c24xx/setup-ts.c
index f61f02bdc52f..46466d20257e 100644
--- a/arch/arm/mach-s3c24xx/setup-ts.c
+++ b/arch/arm/mach-s3c24xx/setup-ts.c
@@ -15,6 +15,7 @@
 
 struct platform_device; /* don't need the contents */
 
+#include plat/gpio-cfg.h
 #include mach/hardware.h
 #include mach/gpio-samsung.h
 
diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
index e34d499cb316..f23782683a7c 100644
--- a/drivers/mmc/host/s3cmci.c
+++ b/drivers/mmc/host/s3cmci.c
@@ -23,6 +23,7 @@
 #include linux/irq.h
 #include linux/io.h
 
+#include plat/gpio-cfg.h
 #include mach/dma.h
 #include mach/gpio-samsung.h
 
-- 
1.8.4.2

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2 v3] ARM: s3c24xx: get rid of custom mach/gpio.h

2014-01-08 Thread Linus Walleij
On Tue, Jan 7, 2014 at 8:52 PM, Arnd Bergmann a...@arndb.de wrote:
 On Tuesday 07 January 2014, Linus Walleij wrote:

 It appears that these problems appear if you explicitly
 enable the DT board support, can't we just put that into
 the defconfig then, so we don't miss such things?

 I don't understand. I didn't enable it manually and
 I still get it on linux-next-20130107. Maybe you were
 still on the older linux-next that had not been updated
 for some time?

No that's not the problem, I used the latest... but:

(...)
 I just tried building with make allmodconfig KCONFIG_ALLCONFIG=allconfig,
 with the allconfig file containing a CONFIG_MACH_S3C2410=y statement.
 This caught a number of additionl problems, some related and some not.

This was the problem, so making new build rules now
to see if I can catch this.

 What is actually the bigger worry here is that the contents
 of the new file, while correctly moved out of mach/gpio.h also
 don't belong into include/linux/platform_data, because they don't
 define a pdata structure but rather the contents that are supposed
 to be passed from the platform code. I would much prefer if you could
 move the file back into mach-s3c24xx/ under a new name and keep it out of
 platform_data.

Unfortunately it cannot live right under mach-s3c24xx because there
are drivers here and there referring directly to the contents of this
file.

The only quick-fix option would be to move it back to
mach/gpio-samsung-s3c24xx.h
but the real solution is of course to augment all drivers to use
gpio descriptors and add descriptor tables to the boardfiles.

I'm a bit reluctant to do that as I'd prefer to be able to test
such modifications on HW ... plus time may be better invested
in DT migration (as I think is the conclusion of this thread
eventually).

 I suspect that the only thing actually needed by the
 gpio driver is the number of GPIO lines per platform, and we can
 find another way to communicate that.

A bit more: if you look in drivers/gpio/gpio-samsung.c you see
bank base GPIO offset for each bank into the global scope
*and* the number of GPIOs for each bank propagated from
machine headers instead of using platform data.

Again the proper solution (if the boardfiles are kept) is to switch
to using a GPIO descriptor table. Or using DT.

 Most of the contents should
 be private to the mach-s3c code and not be visible to either the
 gpio driver or any drivers using the plat/gpio-cfg.h interface.

Samsungs plat/gpio-cfg.h is basically a custom legacy pin
control implementation.

The real solution to getting rid of that file is to switch over
to using pinctrl-[samsung|s3c24xx] which as Heiko describes
mandates also using DT, and thus blocks attempts
at using this path for fixing the legacy boardfiles.

It's one of these situations where we end up with an
all-or-nothing conversion path: either you change everything
over to device tree or everything stays in two copies ...
I'm trying to refactor the existing board files here maybe
that is in vain :-/ as GPIO maintainer I want to get rid of
mach/gpio.h.

  Note that on Exynos, the solution for the gpio driver dependencies
  was to scrap the driver and use pinctrl-exynos instead.

 I think the S3C driver is a different piece of hardware unfortunately.

 But exynos was using this driver before it moved to the new pinctrl
 driver.

I was wrong about this, too much in my head. As Tomasz says,
pinctrl-samsung can be used, but mandates that everything is
moved over to device tree.

Probably the best thing now that I have one problem less is to
leave it to the S3C maintainers to complete their DT migration?

Yours,
Linus Walleij
--
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 v3] ARM: s3c24xx: get rid of custom mach/gpio.h

2014-01-07 Thread Linus Walleij
On Tue, Jan 7, 2014 at 12:15 PM, Arnd Bergmann a...@arndb.de wrote:
 On Friday 13 December 2013, Linus Walleij wrote:
 This isolates the custom S3C24xx GPIO definition table to
 linux/platform_data/gpio-samsung-s3x24xx.h as this is
 used in a few different places in the kernel, removing the
 need to depend on the implicit inclusion of mach/gpio.h
 from linux/gpio.h and thus getting rid of a few nasty
 cross-dependencies.

 We also delete the nifty CONFIG_S3C24XX_GPIO_EXTRA stuff.
 The biggest this can ever be for the S3C24XX is
 CONFIG_S3C24XX_GPIO_EXTRA = 128, and then for CPU_S3C2443 or
 CPU_S3C2416 32*12 GPIOs are added, so 32*12+128 = 512
 is the absolute roof value on this platform. So we set
 the size of ARCH_NR_GPIO to this and the GPIOs array will
 fit any S3C24XX platform, as per pattern from other archs.

 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: Sylwester Nawrocki sylvester.nawro...@gmail.com
 Cc: Ben Dooks ben-li...@fluff.org
 Cc: linux-samsung-soc@vger.kernel.org
 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Heiko Stuebner he...@sntech.de
 Tested-by: Heiko Stuebner he...@sntech.de
 Signed-off-by: Linus Walleij linus.wall...@linaro.org

 I'm getting build errors in linux-next for s3c2410_defconfig now
 because of this patch :(

Hm. I just compiled this defconfig on linux-next:

  AS  arch/arm/boot/compressed/lib1funcs.o
  AS  arch/arm/boot/compressed/ashldi3.o
  AS  arch/arm/boot/compressed/bswapsdi2.o
  CC  arch/arm/boot/compressed/decompress.o
  CC  arch/arm/boot/compressed/misc.o
  GZIParch/arm/boot/compressed/piggy.gzip
  AS  arch/arm/boot/compressed/piggy.gzip.o
  LD  arch/arm/boot/compressed/vmlinux
  OBJCOPY arch/arm/boot/zImage
  Kernel: arch/arm/boot/zImage is ready

It appears that these problems appear if you explicitly
enable the DT board support, can't we just put that into
the defconfig then, so we don't miss such things?

 Two problems:

 * Some files that use functions or macros defined in this file
   fail to include it. I see drivers/leds/leds-s3c24xx.c

I merged a patch fixing this by having that file explicitly include
plat/gpip-cfg.h (it was already including it implicitly).

 and
   mach-osiris-dvs.c,

It needs this:
#include linux/platform_data/gpio-samsung-s3c24xx.h

(I have sent a patch.)

 but there might be more that don't get built
   by default.

Yeah implicit includes are a nightmare for refactoring...
I'm trying to grep around for some symbols to see if I
can find some lost cases.

 * The file includes plat/gpio-cfg.h, which is not a bug yet, but
   will be once we move s3c24xx to multiplatform, which would make
   it impossible to include this file from outside of arch/arm.

Yes that needs to be a step for multiplatform enablement.
My series only tries to make the problem smaller and remove
the dependence on mach/gpio.h. All the mach/* and
plat/* stuff needs to go away eventually ...

 Note that on Exynos, the solution for the gpio driver dependencies
 was to scrap the driver and use pinctrl-exynos instead.

I think the S3C driver is a different piece of hardware unfortunately.

Yours,
Linus Walleij
--
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: S3C24XX: Fix configuration of gpio port sizes on S3C24XX.

2014-01-02 Thread Linus Walleij
On Wed, Sep 11, 2013 at 10:46 AM, José Miguel Gonçalves
jose.goncal...@inov.pt wrote:

 Some GPIO line limits are incorrectly set which, for instance,
 does not allow nRTS1 (GPH11) configuration on a S3C2416 chip.

 Signed-off-by: José Miguel Gonçalves jose.goncal...@inov.pt

Patch applied with Kukjin's ACK and Heiko's review tag.

Yours,
Linus Walleij
--
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: S3C24XX: Fix configuration of gpio port sizes on S3C24XX.

2013-12-20 Thread Linus Walleij
On Fri, Dec 13, 2013 at 10:37 AM, Linus Walleij
linus.wall...@linaro.org wrote:
 On Fri, Dec 13, 2013 at 10:24 AM,  kg...@kernel.org wrote:
 José Miguel Gonçalves wrote:
 (..)
 Was this patch forgotten?

 Hi Jose,

 Sorry about missing your patch. It's my fault :( and as you know, at this
 moment the file will be removed by Linus' patch...

 Oh I can certainly rebase the patch onto my tree if I just
 get an ACK for it...

Kukjin, can I have your ACK for this patch?

Yours,
Linus Walleij
--
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: S3C24XX: Fix configuration of gpio port sizes on S3C24XX.

2013-12-13 Thread Linus Walleij
On Fri, Dec 13, 2013 at 2:55 AM, José Miguel Gonçalves
jose.goncal...@inov.pt wrote:
 On 27-09-2013 15:17, Linus Walleij wrote:
 On Wed, Sep 11, 2013 at 10:46 AM, José Miguel Gonçalves
 jose.goncal...@inov.pt wrote:

 Some GPIO line limits are incorrectly set which, for instance,
 does not allow nRTS1 (GPH11) configuration on a S3C2416 chip.

 Signed-off-by: José Miguel Gonçalves jose.goncal...@inov.pt
 ---
   arch/arm/mach-s3c24xx/include/mach/gpio.h |   10 +-
(...)

 Was this patch forgotten?

Not by me, I just never got an ACK from the Samsung maintainers,
so I can't apply it to the GPIO tree.

Ben, Kukjin: can one of you ACK this so I can take it through the
GPIO tree?

Yours,
Linus Walleij
--
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: s3c24xx: get rid of custom mach/gpio.h

2013-12-13 Thread Linus Walleij
On Fri, Dec 13, 2013 at 8:57 AM, Heiko Stübner he...@sntech.de wrote:

 I'm not the maintainer of s3c24xx,

Maybe you should be. I have a hard time getting the generic
Samsung maintainers' attention to S3C patches...

 but this looks nice ;-)

Do you think you can test it on hardware?

Yours,
Linus Walleij
--
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: S3C24XX: Fix configuration of gpio port sizes on S3C24XX.

2013-12-13 Thread Linus Walleij
On Fri, Dec 13, 2013 at 10:24 AM,  kg...@kernel.org wrote:
 José Miguel Gonçalves wrote:
(..)
 Was this patch forgotten?

 Hi Jose,

 Sorry about missing your patch. It's my fault :( and as you know, at this
 moment the file will be removed by Linus' patch...

Oh I can certainly rebase the patch onto my tree if I just
get an ACK for it...

Yours,
Linus Walleij
--
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: s3c24xx: get rid of custom mach/gpio.h

2013-12-13 Thread Linus Walleij
On Fri, Dec 13, 2013 at 11:30 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
 On Thursday 12 of December 2013 15:06:50 Linus Walleij wrote:
 [snip]
  arch/arm/mach-s3c64xx/include/mach/gpio.h  |  93 -

 Hmm, shouldn't this (and other s3c64xx-related changes) be in patch 2/2?

Hm yes, I wonder how I screwed this up... I'll move this to the other patch.

 Anyway, I've applied both, but unfortunately compilation for mach-s3c64xx
 (using s3c6400_defconfig) fails with following error:

Trying to reproduce and fix this.

Thanks!

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/2 v3] ARM: s3c24xx: get rid of custom mach/gpio.h

2013-12-13 Thread Linus Walleij
This isolates the custom S3C24xx GPIO definition table to
linux/platform_data/gpio-samsung-s3x24xx.h as this is
used in a few different places in the kernel, removing the
need to depend on the implicit inclusion of mach/gpio.h
from linux/gpio.h and thus getting rid of a few nasty
cross-dependencies.

We also delete the nifty CONFIG_S3C24XX_GPIO_EXTRA stuff.
The biggest this can ever be for the S3C24XX is
CONFIG_S3C24XX_GPIO_EXTRA = 128, and then for CPU_S3C2443 or
CPU_S3C2416 32*12 GPIOs are added, so 32*12+128 = 512
is the absolute roof value on this platform. So we set
the size of ARCH_NR_GPIO to this and the GPIOs array will
fit any S3C24XX platform, as per pattern from other archs.

Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Sylwester Nawrocki sylvester.nawro...@gmail.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: linux-samsung-soc@vger.kernel.org
Acked-by: Kukjin Kim kgene@samsung.com
Acked-by: Heiko Stuebner he...@sntech.de
Tested-by: Heiko Stuebner he...@sntech.de
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
ChangeLog v2-v3:
- Move the movement of the S3C64XX gpio.h file out of
  this patch and into the follow-up patch where it belongs.
ChangeLog v1-v2:
- Added an #ifdef ARCH_S3C24XX around the header inclusion
  in drivers/gpio/gpio-samsung.c as we would otherwise
  have colliding definitions when compiling S3C64XX.
- Rename inclusion guard in the header file.

I will take this through the GPIO tree.
---
 arch/arm/Kconfig   |   3 +-
 arch/arm/mach-s3c24xx/Kconfig  |  21 
 arch/arm/mach-s3c24xx/common-smdk.c|   2 +-
 arch/arm/mach-s3c24xx/h1940-bluetooth.c|   1 +
 arch/arm/mach-s3c24xx/include/mach/gpio.h  | 114 -
 arch/arm/mach-s3c24xx/mach-amlm5900.c  |   1 +
 arch/arm/mach-s3c24xx/mach-anubis.c|   1 +
 arch/arm/mach-s3c24xx/mach-at2440evb.c |   1 +
 arch/arm/mach-s3c24xx/mach-bast.c  |   1 +
 arch/arm/mach-s3c24xx/mach-gta02.c |   1 +
 arch/arm/mach-s3c24xx/mach-h1940.c |   1 +
 arch/arm/mach-s3c24xx/mach-jive.c  |   1 +
 arch/arm/mach-s3c24xx/mach-mini2440.c  |   1 +
 arch/arm/mach-s3c24xx/mach-n30.c   |   1 +
 arch/arm/mach-s3c24xx/mach-nexcoder.c  |   1 +
 arch/arm/mach-s3c24xx/mach-osiris.c|   1 +
 arch/arm/mach-s3c24xx/mach-qt2410.c|   1 +
 arch/arm/mach-s3c24xx/mach-rx1950.c|   1 +
 arch/arm/mach-s3c24xx/mach-rx3715.c|   1 +
 arch/arm/mach-s3c24xx/mach-smdk2413.c  |   1 +
 arch/arm/mach-s3c24xx/mach-smdk2416.c  |   1 +
 arch/arm/mach-s3c24xx/mach-vr1000.c|   1 +
 arch/arm/mach-s3c24xx/pm-s3c2410.c |   1 +
 arch/arm/mach-s3c24xx/pm.c |   1 +
 arch/arm/mach-s3c24xx/s3c2410.c|   1 +
 arch/arm/mach-s3c24xx/s3c2416.c|   1 +
 arch/arm/mach-s3c24xx/s3c2440.c|   1 +
 arch/arm/mach-s3c24xx/s3c2442.c|   1 +
 arch/arm/mach-s3c24xx/s3c2443.c|   1 +
 arch/arm/mach-s3c24xx/setup-i2c.c  |   1 +
 arch/arm/mach-s3c24xx/setup-sdhci-gpio.c   |   1 +
 arch/arm/mach-s3c24xx/setup-ts.c   |   1 +
 arch/arm/mach-s3c24xx/simtec-usb.c |   1 +
 arch/arm/plat-samsung/pm-gpio.c|   3 +
 arch/arm/plat-samsung/setup-camif.c|   1 +
 drivers/gpio/gpio-samsung.c|   3 +
 drivers/mmc/host/s3cmci.c  |   1 +
 include/linux/platform_data/gpio-samsung-s3c24xx.h | 106 +++
 38 files changed, 145 insertions(+), 138 deletions(-)
 delete mode 100644 arch/arm/mach-s3c24xx/include/mach/gpio.h
 create mode 100644 include/linux/platform_data/gpio-samsung-s3c24xx.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c1f1a7eee953..6a26bcb3a63a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -710,7 +710,6 @@ config ARCH_S3C24XX
select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_S3C_RTC if RTC_CLASS
select MULTI_IRQ_HANDLER
-   select NEED_MACH_GPIO_H
select NEED_MACH_IO_H
select SAMSUNG_ATAGS
help
@@ -1593,7 +1592,7 @@ config ARM_PSCI
 config ARCH_NR_GPIO
int
default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
-   default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX
+   default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX 
|| ARCH_S3C24XX
default 392 if ARCH_U8500
default 352 if ARCH_VT8500
default 288 if ARCH_SUNXI
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 8f1d327e0cd1..d876431d64c0 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -180,27 +180,6 @@ config CPU_LLSERIAL_S3C2440

[PATCH 2/2 v2] ARM: s3c64xx: get rid of custom mach/gpio.h

2013-12-13 Thread Linus Walleij
This isolates the custom S3C64xx GPIO definition table to
linux/platform_data/gpio-samsung-s3x64xx.h as this is
used in a few different places in the kernel, removing the
need to depend on the implicit inclusion of mach/gpio.h
from linux/gpio.h and thus getting rid of a few nasty
cross-dependencies.

Also delete the CONFIG_SAMSUNG_GPIO_EXTRA stuff. Instead
roof the number of GPIOs for this platform:
First sum up all the GPIO banks from A to Q: 187 GPIOs.
Add the 16 board GPIOs and the roof for SAMSUNG_GPIO_EXTRA,
128, so in total maximum 187+16+128 = 331 GPIOs, so let's
take the same roof as for S3C24XX: 512. This way we can do
away with the GPIO calculation macros for GPIO_BOARD_START,
BOARD_NR_GPIOS and the definition of ARCH_NR_GPIOS.

Cc: Mark Brown broo...@kernel.org
Cc: Tomasz Figa tomasz.f...@gmail.com
Acked-by: Kukjin Kim kgene@samsung.com
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
ChangeLog v1-v2:
- Move the movement of the actual gpio.h file into this
  patch after mistakenly having it end up in the S3C24xx
  patch.
- Add a missing ifdef for the pm-gpio.c code in
  plat-samsung.

This patch depends on
ARM: s3c24xx: get rid of custom mach/gpio.h

I will take this through the GPIO tree.
---
 arch/arm/Kconfig   |  3 +-
 arch/arm/mach-s3c64xx/Kconfig  |  3 -
 arch/arm/mach-s3c64xx/common.c |  1 +
 arch/arm/mach-s3c64xx/crag6410.h   |  2 +-
 arch/arm/mach-s3c64xx/dev-audio.c  |  1 +
 arch/arm/mach-s3c64xx/include/mach/gpio.h  | 93 -
 arch/arm/mach-s3c64xx/mach-anw6410.c   |  1 +
 arch/arm/mach-s3c64xx/mach-crag6410.c  |  1 +
 arch/arm/mach-s3c64xx/mach-hmt.c   |  1 +
 arch/arm/mach-s3c64xx/mach-mini6410.c  |  1 +
 arch/arm/mach-s3c64xx/mach-real6410.c  |  1 +
 arch/arm/mach-s3c64xx/mach-smartq.c|  1 +
 arch/arm/mach-s3c64xx/mach-smartq5.c   |  1 +
 arch/arm/mach-s3c64xx/mach-smartq7.c   |  1 +
 arch/arm/mach-s3c64xx/mach-smdk6400.c  |  1 +
 arch/arm/mach-s3c64xx/mach-smdk6410.c  |  1 +
 arch/arm/mach-s3c64xx/pm.c |  1 +
 arch/arm/mach-s3c64xx/setup-fb-24bpp.c |  1 +
 arch/arm/mach-s3c64xx/setup-i2c0.c |  1 +
 arch/arm/mach-s3c64xx/setup-i2c1.c |  1 +
 arch/arm/mach-s3c64xx/setup-ide.c  |  1 +
 arch/arm/mach-s3c64xx/setup-keypad.c   |  1 +
 arch/arm/mach-s3c64xx/setup-sdhci-gpio.c   |  1 +
 arch/arm/mach-s3c64xx/setup-spi.c  |  1 +
 arch/arm/plat-samsung/pm-gpio.c|  3 +
 drivers/gpio/gpio-samsung.c|  3 +
 include/linux/platform_data/gpio-samsung-s3c64xx.h | 94 ++
 27 files changed, 122 insertions(+), 99 deletions(-)
 delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio.h
 create mode 100644 include/linux/platform_data/gpio-samsung-s3c64xx.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6a26bcb3a63a..103437986684 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -732,7 +732,6 @@ config ARCH_S3C64XX
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_TCM
-   select NEED_MACH_GPIO_H
select NO_IOPORT
select PLAT_SAMSUNG
select PM_GENERIC_DOMAINS
@@ -1592,7 +1591,7 @@ config ARM_PSCI
 config ARCH_NR_GPIO
int
default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
-   default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX 
|| ARCH_S3C24XX
+   default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX 
|| ARCH_S3C24XX || ARCH_S3C64XX
default 392 if ARCH_U8500
default 352 if ARCH_VT8500
default 288 if ARCH_SUNXI
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 2cb8dc55b50e..175f01501129 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -192,7 +192,6 @@ config SMDK6410_WM1190_EV1
select MFD_WM8350_I2C
select REGULATOR
select REGULATOR_WM8350
-   select SAMSUNG_GPIO_EXTRA64
help
  The Wolfson Microelectronics 1190-EV1 is a WM835x based PMIC
  and audio daughtercard for the Samsung SMDK6410 reference
@@ -208,7 +207,6 @@ config SMDK6410_WM1192_EV1
select MFD_WM831X_I2C
select REGULATOR
select REGULATOR_WM831X
-   select SAMSUNG_GPIO_EXTRA64
help
  The Wolfson Microelectronics 1192-EV1 is a WM831x based PMIC
  daughtercard for the Samsung SMDK6410 reference platform.
@@ -294,7 +292,6 @@ config MACH_WLF_CRAGG_6410
select SAMSUNG_DEV_ADC
select SAMSUNG_DEV_KEYPAD
select SAMSUNG_DEV_PWM
-   select SAMSUNG_GPIO_EXTRA128
help
  Machine support for the Wolfson Cragganmore S3C6410 variant

[PATCH 1/2] ARM: s3c24xx: get rid of custom mach/gpio.h

2013-12-12 Thread Linus Walleij
This isolates the custom S3C24xx GPIO definition table to
linux/platform_data/gpio-samsung-s3x24xx.h as this is
used in a few different places in the kernel, removing the
need to depend on the implicit inclusion of mach/gpio.h
from linux/gpio.h and thus getting rid of a few nasty
cross-dependencies.

We also delete the nifty CONFIG_S3C24XX_GPIO_EXTRA stuff.
The biggest this can ever be for the S3C24XX is
CONFIG_S3C24XX_GPIO_EXTRA = 128, and then for CPU_S3C2443 or
CPU_S3C2416 32*12 GPIOs are added, so 32*12+128 = 512
is the absolute roof value on this platform. So we set
the size of ARCH_NR_GPIO to this and the GPIOs array will
fit any S3C24XX platform, as per pattern from other archs.

Cc: Heiko Stuebner he...@sntech.de
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Sylwester Nawrocki sylvester.nawro...@gmail.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
ChangeLog v1-v2:
- Added an #ifdef ARCH_S3C24XX around the header inclusion
  in drivers/gpio/gpio-samsung.c as we would otherwise
  have colliding definitions when compiling S3C64XX.
- Rename inclusion guard in the header file.

If one of the maintainers give me an ACK for this I will
take it through the GPIO tree.
---
 arch/arm/Kconfig   |   3 +-
 arch/arm/mach-s3c24xx/Kconfig  |  21 
 arch/arm/mach-s3c24xx/common-smdk.c|   2 +-
 arch/arm/mach-s3c24xx/h1940-bluetooth.c|   1 +
 arch/arm/mach-s3c24xx/include/mach/gpio.h  | 114 -
 arch/arm/mach-s3c24xx/mach-amlm5900.c  |   1 +
 arch/arm/mach-s3c24xx/mach-anubis.c|   1 +
 arch/arm/mach-s3c24xx/mach-at2440evb.c |   1 +
 arch/arm/mach-s3c24xx/mach-bast.c  |   1 +
 arch/arm/mach-s3c24xx/mach-gta02.c |   1 +
 arch/arm/mach-s3c24xx/mach-h1940.c |   1 +
 arch/arm/mach-s3c24xx/mach-jive.c  |   1 +
 arch/arm/mach-s3c24xx/mach-mini2440.c  |   1 +
 arch/arm/mach-s3c24xx/mach-n30.c   |   1 +
 arch/arm/mach-s3c24xx/mach-nexcoder.c  |   1 +
 arch/arm/mach-s3c24xx/mach-osiris.c|   1 +
 arch/arm/mach-s3c24xx/mach-qt2410.c|   1 +
 arch/arm/mach-s3c24xx/mach-rx1950.c|   1 +
 arch/arm/mach-s3c24xx/mach-rx3715.c|   1 +
 arch/arm/mach-s3c24xx/mach-smdk2413.c  |   1 +
 arch/arm/mach-s3c24xx/mach-smdk2416.c  |   1 +
 arch/arm/mach-s3c24xx/mach-vr1000.c|   1 +
 arch/arm/mach-s3c24xx/pm-s3c2410.c |   1 +
 arch/arm/mach-s3c24xx/pm.c |   1 +
 arch/arm/mach-s3c24xx/s3c2410.c|   1 +
 arch/arm/mach-s3c24xx/s3c2416.c|   1 +
 arch/arm/mach-s3c24xx/s3c2440.c|   1 +
 arch/arm/mach-s3c24xx/s3c2442.c|   1 +
 arch/arm/mach-s3c24xx/s3c2443.c|   1 +
 arch/arm/mach-s3c24xx/setup-i2c.c  |   1 +
 arch/arm/mach-s3c24xx/setup-sdhci-gpio.c   |   1 +
 arch/arm/mach-s3c24xx/setup-ts.c   |   1 +
 arch/arm/mach-s3c24xx/simtec-usb.c |   1 +
 arch/arm/mach-s3c64xx/include/mach/gpio.h  |  93 -
 arch/arm/plat-samsung/pm-gpio.c|   3 +
 arch/arm/plat-samsung/setup-camif.c|   1 +
 drivers/gpio/gpio-samsung.c|   3 +
 drivers/mmc/host/s3cmci.c  |   1 +
 include/linux/platform_data/gpio-samsung-s3c24xx.h | 106 +++
 include/linux/platform_data/gpio-samsung-s3c64xx.h |  93 +
 40 files changed, 238 insertions(+), 231 deletions(-)
 delete mode 100644 arch/arm/mach-s3c24xx/include/mach/gpio.h
 delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio.h
 create mode 100644 include/linux/platform_data/gpio-samsung-s3c24xx.h
 create mode 100644 include/linux/platform_data/gpio-samsung-s3c64xx.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c1f1a7eee953..6a26bcb3a63a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -710,7 +710,6 @@ config ARCH_S3C24XX
select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_S3C_RTC if RTC_CLASS
select MULTI_IRQ_HANDLER
-   select NEED_MACH_GPIO_H
select NEED_MACH_IO_H
select SAMSUNG_ATAGS
help
@@ -1593,7 +1592,7 @@ config ARM_PSCI
 config ARCH_NR_GPIO
int
default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
-   default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX
+   default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX 
|| ARCH_S3C24XX
default 392 if ARCH_U8500
default 352 if ARCH_VT8500
default 288 if ARCH_SUNXI
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index

[PATCH 2/2] ARM: s3c64xx: get rid of custom mach/gpio.h

2013-12-12 Thread Linus Walleij
This isolates the custom S3C64xx GPIO definition table to
linux/platform_data/gpio-samsung-s3x64xx.h as this is
used in a few different places in the kernel, removing the
need to depend on the implicit inclusion of mach/gpio.h
from linux/gpio.h and thus getting rid of a few nasty
cross-dependencies.

Also delete the CONFIG_SAMSUNG_GPIO_EXTRA stuff. Instead
roof the number of GPIOs for this platform:
First sum up all the GPIO banks from A to Q: 187 GPIOs.
Add the 16 board GPIOs and the roof for SAMSUNG_GPIO_EXTRA,
128, so in total maximum 187+16+128 = 331 GPIOs, so let's
take the same roof as for S3C24XX: 512. This way we can do
away with the GPIO calculation macros for GPIO_BOARD_START,
BOARD_NR_GPIOS and the definition of ARCH_NR_GPIOS.

Cc: Kukjin Kim kgene@samsung.com
Cc: Mark Brown broo...@kernel.org
Cc: Tomasz Figa tomasz.f...@gmail.com
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
This patch depends on
ARM: s3c24xx: get rid of custom mach/gpio.h

If one of the maintainers give me an ACK for this I will
take it through the GPIO tree.
---
 arch/arm/Kconfig   | 3 +--
 arch/arm/mach-s3c64xx/Kconfig  | 3 ---
 arch/arm/mach-s3c64xx/common.c | 1 +
 arch/arm/mach-s3c64xx/crag6410.h   | 2 +-
 arch/arm/mach-s3c64xx/dev-audio.c  | 1 +
 arch/arm/mach-s3c64xx/mach-anw6410.c   | 1 +
 arch/arm/mach-s3c64xx/mach-crag6410.c  | 1 +
 arch/arm/mach-s3c64xx/mach-hmt.c   | 1 +
 arch/arm/mach-s3c64xx/mach-mini6410.c  | 1 +
 arch/arm/mach-s3c64xx/mach-real6410.c  | 1 +
 arch/arm/mach-s3c64xx/mach-smartq.c| 1 +
 arch/arm/mach-s3c64xx/mach-smartq5.c   | 1 +
 arch/arm/mach-s3c64xx/mach-smartq7.c   | 1 +
 arch/arm/mach-s3c64xx/mach-smdk6400.c  | 1 +
 arch/arm/mach-s3c64xx/mach-smdk6410.c  | 1 +
 arch/arm/mach-s3c64xx/pm.c | 1 +
 arch/arm/mach-s3c64xx/setup-fb-24bpp.c | 1 +
 arch/arm/mach-s3c64xx/setup-i2c0.c | 1 +
 arch/arm/mach-s3c64xx/setup-i2c1.c | 1 +
 arch/arm/mach-s3c64xx/setup-ide.c  | 1 +
 arch/arm/mach-s3c64xx/setup-keypad.c   | 1 +
 arch/arm/mach-s3c64xx/setup-sdhci-gpio.c   | 1 +
 arch/arm/mach-s3c64xx/setup-spi.c  | 1 +
 drivers/gpio/gpio-samsung.c| 3 +++
 include/linux/platform_data/gpio-samsung-s3c64xx.h | 9 +
 25 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6a26bcb3a63a..103437986684 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -732,7 +732,6 @@ config ARCH_S3C64XX
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_TCM
-   select NEED_MACH_GPIO_H
select NO_IOPORT
select PLAT_SAMSUNG
select PM_GENERIC_DOMAINS
@@ -1592,7 +1591,7 @@ config ARM_PSCI
 config ARCH_NR_GPIO
int
default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
-   default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX 
|| ARCH_S3C24XX
+   default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX 
|| ARCH_S3C24XX || ARCH_S3C64XX
default 392 if ARCH_U8500
default 352 if ARCH_VT8500
default 288 if ARCH_SUNXI
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 2cb8dc55b50e..175f01501129 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -192,7 +192,6 @@ config SMDK6410_WM1190_EV1
select MFD_WM8350_I2C
select REGULATOR
select REGULATOR_WM8350
-   select SAMSUNG_GPIO_EXTRA64
help
  The Wolfson Microelectronics 1190-EV1 is a WM835x based PMIC
  and audio daughtercard for the Samsung SMDK6410 reference
@@ -208,7 +207,6 @@ config SMDK6410_WM1192_EV1
select MFD_WM831X_I2C
select REGULATOR
select REGULATOR_WM831X
-   select SAMSUNG_GPIO_EXTRA64
help
  The Wolfson Microelectronics 1192-EV1 is a WM831x based PMIC
  daughtercard for the Samsung SMDK6410 reference platform.
@@ -294,7 +292,6 @@ config MACH_WLF_CRAGG_6410
select SAMSUNG_DEV_ADC
select SAMSUNG_DEV_KEYPAD
select SAMSUNG_DEV_PWM
-   select SAMSUNG_GPIO_EXTRA128
help
  Machine support for the Wolfson Cragganmore S3C6410 variant.
 
diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index 7a3ce4c39e5f..64edda37bde3 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -32,6 +32,7 @@
 #include linux/irq.h
 #include linux/gpio.h
 #include linux/irqchip/arm-vic.h
+#include linux/platform_data/gpio-samsung-s3c64xx.h
 #include clocksource/samsung_pwm.h
 
 #include asm/mach/arch.h
diff --git a/arch/arm/mach-s3c64xx/crag6410.h b/arch/arm/mach

Re: [PATCH CFT] ARM:S5P64X0: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default

2013-12-12 Thread Linus Walleij
On Thu, Dec 12, 2013 at 10:47 AM, Tomasz Figa tomasz.f...@gmail.com wrote:

 This is actually quite a poor platform choice. As of today, the kernel
 is stuck with supporting just SMDK6440/6450 boards, which are proprietary
 development boards and it doesn't look like any further boards will show
 up in future. Kukjin has actually proposed removing support for this
 platform at all and I consider this reasonable.

 Kukjin, should we proceed with removal?

Isn't Mark Brown using that platform for some various stuff?

Yours,
Linus Walleij
--
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 CFT] ARM:S5P64X0: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default

2013-12-12 Thread Linus Walleij
On Thu, Dec 12, 2013 at 10:22 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
 2013/12/12 Linus Walleij linus.wall...@linaro.org:
 On Thu, Dec 12, 2013 at 10:47 AM, Tomasz Figa tomasz.f...@gmail.com wrote:

 This is actually quite a poor platform choice. As of today, the kernel
 is stuck with supporting just SMDK6440/6450 boards, which are proprietary
 development boards and it doesn't look like any further boards will show
 up in future. Kukjin has actually proposed removing support for this
 platform at all and I consider this reasonable.

 Kukjin, should we proceed with removal?

 Isn't Mark Brown using that platform for some various stuff?

 Not as far as I know.

 He's using Cragganmore board based on s3c6410, but this is a different
 platform (s3c64xx).

A I see it now. So the S3C:s are actually in a lot of use
and the S5P is one of those stepping stones to Exynos that
never really was in any widespread use.

Yeah I'm all for deleteing that :-)

Thanks!
Linus Walleij
--
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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.

2013-12-09 Thread Linus Walleij
On Thu, Dec 5, 2013 at 4:07 PM, Mark Brown broo...@kernel.org wrote:
 On Tue, Dec 03, 2013 at 10:29:42AM +0100, Linus Walleij wrote:

 So a suggested patch to support weak hogs would be interesting
 to look at. Can you provide details on how you think this would
 work?

 Or should we be going and applying the default state to all devices on
 init without worrying about a driver appearing?

That doesn't really work: if you have an unused device not in the
DT you usually mark it disabled, and then the DT core doesn't
even create a platform_device for this node.

So doing this would involve parsing the tree and ... yuck.

Yours,
Linus Walleij
--
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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.

2013-12-09 Thread Linus Walleij
On Fri, Dec 6, 2013 at 12:54 AM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 12/03/2013 02:29 AM, Linus Walleij wrote:

(skipped the conversation on weak hogs, we are on the same page
here, just waiting for someone to start working on it ...)

 Related, I prefer to put /all/ static pinctrl configuration into the
 pinctrl device's default state (i.e. use a hog) rather than
 configuring the static pinctrl setup per device, for another reason too:

 If a particular IO controller's signals can be routed to n different
 (sets of) pins, then we need to do *both* of the following when setting
 up the pinmux:

 a) Configure the pins we want to host those signals to route to/from
 that particular IO controller.

 b) Configure any other pins that could route to/from that particular IO
 controller as some other function; either disabled, or routed to/from
 some different IO controller.

 That is so that the IO controller's RX/input signals are not connected
 from two different sets of pins at once, which would cause two things to
 driver them. Depending on HW, this could cause on of:

 1) Multiple drivers - high power usage, or even Silicon damage.

 2) Inconsistent configuration, with the wrong set of pins driving the
 IO controller's inputs, and hence the signals on the correct pins
 being ignored - hard to find bug.

I'm following, I think what we need here is to think about additional
behaviours and electronic constraints we can encode into the drivers
and/or the pin tables to safeguard pin states from electronically
unsound states.

That is to say, I prefer the subsystem to be conscious about the
electronic constraints and navigate around them or put up a road
block, rather than trying ti avoid driving into the roadblocks by means
of carefully crafted tables if you get the picture ...

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ARM: s3c24xx: get rid of custom mach/gpio.h

2013-12-06 Thread Linus Walleij
This isolates the custom S3C24xx GPIO definition table to
linux/platform_data/gpio-samsung-s3x24xx.h as this is
used in a few different places in the kernel, removing the
need to depend on the implicit inclusion of mach/gpio.h
from linux/gpio.h and thus getting rid of a few nasty
cross-dependencies.

We also delete the nifty CONFIG_S3C24XX_GPIO_EXTRA stuff.
The biggest this can ever be for the S3C24XX is
CONFIG_S3C24XX_GPIO_EXTRA = 128, and then for CPU_S3C2443 or
CPU_S3C2416 32*12 GPIOs are added, so 32*12+128 = 512
is the absolute roof value on this platform. So we set
the size of ARCH_NR_GPIO to this and the GPIOs array will
fit any S3C24XX platform, as per pattern from other archs.

Cc: Heiko Stuebner he...@sntech.de
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Sylwester Nawrocki sylvester.nawro...@gmail.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
If one of the maintainers give me an ACK for this I will
take it through the GPIO tree.
---
 arch/arm/Kconfig   |   3 +-
 arch/arm/mach-s3c24xx/Kconfig  |  21 
 arch/arm/mach-s3c24xx/common-smdk.c|   2 +-
 arch/arm/mach-s3c24xx/h1940-bluetooth.c|   1 +
 arch/arm/mach-s3c24xx/include/mach/gpio.h  | 114 -
 arch/arm/mach-s3c24xx/mach-amlm5900.c  |   1 +
 arch/arm/mach-s3c24xx/mach-anubis.c|   1 +
 arch/arm/mach-s3c24xx/mach-at2440evb.c |   1 +
 arch/arm/mach-s3c24xx/mach-bast.c  |   1 +
 arch/arm/mach-s3c24xx/mach-gta02.c |   1 +
 arch/arm/mach-s3c24xx/mach-h1940.c |   1 +
 arch/arm/mach-s3c24xx/mach-jive.c  |   1 +
 arch/arm/mach-s3c24xx/mach-mini2440.c  |   1 +
 arch/arm/mach-s3c24xx/mach-n30.c   |   1 +
 arch/arm/mach-s3c24xx/mach-nexcoder.c  |   1 +
 arch/arm/mach-s3c24xx/mach-osiris.c|   1 +
 arch/arm/mach-s3c24xx/mach-qt2410.c|   1 +
 arch/arm/mach-s3c24xx/mach-rx1950.c|   1 +
 arch/arm/mach-s3c24xx/mach-rx3715.c|   1 +
 arch/arm/mach-s3c24xx/mach-smdk2413.c  |   1 +
 arch/arm/mach-s3c24xx/mach-smdk2416.c  |   1 +
 arch/arm/mach-s3c24xx/mach-vr1000.c|   1 +
 arch/arm/mach-s3c24xx/pm-s3c2410.c |   1 +
 arch/arm/mach-s3c24xx/pm.c |   1 +
 arch/arm/mach-s3c24xx/s3c2410.c|   1 +
 arch/arm/mach-s3c24xx/s3c2416.c|   1 +
 arch/arm/mach-s3c24xx/s3c2440.c|   1 +
 arch/arm/mach-s3c24xx/s3c2442.c|   1 +
 arch/arm/mach-s3c24xx/s3c2443.c|   1 +
 arch/arm/mach-s3c24xx/setup-i2c.c  |   1 +
 arch/arm/mach-s3c24xx/setup-sdhci-gpio.c   |   1 +
 arch/arm/mach-s3c24xx/setup-ts.c   |   1 +
 arch/arm/mach-s3c24xx/simtec-usb.c |   1 +
 arch/arm/plat-samsung/pm-gpio.c|   1 +
 arch/arm/plat-samsung/setup-camif.c|   1 +
 drivers/gpio/gpio-samsung.c|   1 +
 drivers/mmc/host/s3cmci.c  |   1 +
 include/linux/platform_data/gpio-samsung-s3c24xx.h | 106 +++
 38 files changed, 141 insertions(+), 138 deletions(-)
 delete mode 100644 arch/arm/mach-s3c24xx/include/mach/gpio.h
 create mode 100644 include/linux/platform_data/gpio-samsung-s3c24xx.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c1f1a7eee953..6a26bcb3a63a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -710,7 +710,6 @@ config ARCH_S3C24XX
select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_S3C_RTC if RTC_CLASS
select MULTI_IRQ_HANDLER
-   select NEED_MACH_GPIO_H
select NEED_MACH_IO_H
select SAMSUNG_ATAGS
help
@@ -1593,7 +1592,7 @@ config ARM_PSCI
 config ARCH_NR_GPIO
int
default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
-   default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX
+   default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX 
|| ARCH_S3C24XX
default 392 if ARCH_U8500
default 352 if ARCH_VT8500
default 288 if ARCH_SUNXI
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 8f1d327e0cd1..d876431d64c0 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -180,27 +180,6 @@ config CPU_LLSERIAL_S3C2440
  Selected if there is an S3C2440 (or register compatible) serial
  low-level implementation needed
 
-# gpio configurations
-
-config S3C24XX_GPIO_EXTRA
-   int
-   default 128 if S3C24XX_GPIO_EXTRA128
-   default 64 if S3C24XX_GPIO_EXTRA64
-   default 16 if ARCH_H1940
-   default 0
-
-config S3C24XX_GPIO_EXTRA64
-   bool

Re: [PATCH] ARM: s3c24xx: get rid of custom mach/gpio.h

2013-12-06 Thread Linus Walleij
On Fri, Dec 6, 2013 at 10:31 AM, Linus Walleij linus.wall...@linaro.org wrote:

 This isolates the custom S3C24xx GPIO definition table to
 linux/platform_data/gpio-samsung-s3x24xx.h

Maybe I'm too trigger happy. I'll send a combined series with
S3C24xx, S3C64xx and maybe also S5P variants all fixed
so you can see the overall idea here. Hold on.

Yours,
Linus Walleij
--
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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.

2013-12-03 Thread Linus Walleij
On Mon, Nov 25, 2013 at 9:01 PM, Kevin Bracey ke...@bracey.fi wrote:

 I've been working on extending the shmobile PFC driver to provide
 gpio-mode and implement PIN_CONFIG_OUTPUT as described by
 Documentation/pinctrl.txt, primarily to handle sleep states, but I have
 begun to wonder about the initial state problem, as discussed here.

 As far as I can see, we can't currently specify fallback states for pins,
 which is one of Tomasz' key requirements.

That depends on what you mean with fallback states so let's hash
this out.

 We can specify hog states, and we can specify default for a driver, but
 not default before/in absence of a driver or sleep in absence of a
 driver. Having a hog precludes any finer driver control, AFAICT.

So the way it currently works is that hogs are usually used when
there is no corresponding driver that can take care of the pins.

If there are four SPI pins and no driver for that SPI block, a way
to e.g. ground them is to do so using pinctrl hogs.

Whenever a driver and a struct device * for this SPI block appears,
it is wise to transfer control of these over to the device core, which
will take any default state before doing probe() on the device
driver, and then give you the option to use the nice pinctrl_pm*
accessors to let the device core switch between default idle
and sleep states if these are defined.

 Some of our existing pre-pinconf board files have a unused pins table
 which is used to claim and pull GPIOs. I've converted that to hog pinconf,
 but that only works because the table omits all pins used by drivers. And,
 unsurprisingly, that's been error-prone; if those tables originally covered
 all unused pins, they don't any more.

 I'd like confidence that we can get every pin into the correct state by
 having a fully-populated table containing all pins, that can be used
 regardless of which drivers start. I think what we're lacking is a weak
 hog. Whatever you call that. :)

 That would also specify the state to fallback to when a group is released
 (where we currently do pinmux_disable_setting).

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?

It is true that we currently require the tables to be strict and not
overlap like this, so ideally you should remove the hogs when you
have a device driver, but you're actually describing an interesting
case here:

What if I have a driver for this IP block, and it was supposed to
take care of a few pins, but I decide not to compile it into my
kernel? Or if I have it as a module and only modprobe it later
at runtime?

So a suggested patch to support weak hogs would be interesting
to look at. Can you provide details on how you think this would
work?

Yours,
Linus Walleij
--
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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.

2013-12-03 Thread Linus Walleij
On Tue, Nov 26, 2013 at 1:30 AM, Tomasz Figa tomasz.f...@gmail.com wrote:

 IMHO a way to specify a default safe state of all pins (with lowest power
 consumption, without possibility of glitching external devices, etc.)
 would be really useful for Samsung platforms (and probably Renesas ones
 as Kevin wrote).

I'm following :-)

Now if we could see some more details and a patch, that would
be great ...

Yours,
Linus Walleij
--
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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.

2013-11-25 Thread Linus Walleij
On Wed, Nov 20, 2013 at 1:02 AM, Kyungmin Park kmp...@infradead.org wrote:
 On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren swar...@wwwdotorg.org wrote:

 I think that last point should be addressed by having a driver that owns
 the GPIO set it to the desired output level, and the implementation of

 Some pins are not connected (NC). At that cases, there's no drivers to
 handle it. To reduce power leakage, it sets proper configuration with
 values instead of reset values.

This is correspondant to the PIN_CONFIG_OUTPUT from
include/linux/pinctrl/pinconf-generic.h

I.e. driving a pin - any pin, even one that cannot do GPIO - high
or low as default.

One could argue that if you can drive the pin high/low using
software then by definition it *is* GPIO. Even if it cannot trigger
IRQs or anything.

The rationale for having it in pinconf-generic is basically for
use cases such that one of the the pin config states the device
pass through may relate to what the documentation calls
the GPIO mode fallacy - a state on the pins that is definately
related to the use case of a certain device, but puts the pin
in something the manual calls GPIO mode in order to save
power.

But from a use case point of view that is not GPIO, it is the
typically the sleep state of a certain pin when used with a
certain device.

I'll see if I can think of some doc patch to make this more clear...

Yours,
Linus Walleij
--
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] pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes

2013-11-25 Thread Linus Walleij
On Wed, Nov 20, 2013 at 3:00 PM, Tomasz Figa t.f...@samsung.com wrote:
 Stephen:
 Is the lifetime of the string returned by
 of_property_read_string_index() really so short that you must copy the
 string? I'd be tempted just to store the pointer, although perhaps you
 need to get() the node so that's safe.

 Right. I have done it the copy-less way in other places, but missed this
 one. Thanks.

So I guess I'm waiting for a new version of this patch, right?

Yours,
Linus Walleij
--
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] pinctrl: Correct number of pins for s5pv210

2013-09-27 Thread Linus Walleij
On Tue, Sep 24, 2013 at 5:04 PM, Mateusz Krawczuk
m.krawc...@partner.samsung.com wrote:

 Values of pins in table s5pv210 bank are incorrect. This patch correct values.

 Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

Patch applied for fixes with the ACKs from Tomasz and Kukjin.

Yours,
Linus Walleij
--
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


  1   2   3   >