* Re: [PATCH 11/15] sound: soc: poodle: make use of new locomo GPIO interface
From: Alexandre Courbot @ 2014-11-01 5:42 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: Linus Walleij, Mark Brown, linux-arm-kernel@lists.infradead.org,
linux-gpio@vger.kernel.org, Linux Input,
linux-leds@vger.kernel.org, linux-spi@vger.kernel.org,
linux-fbdev@vger.kernel.org, alsa-devel@alsa-project.org,
Andrea Adami, Russell King, Daniel Mack, Haojian Zhuang,
Robert Jarzmik, Dmitry Torokhov, Bryan Wu, Richard Purdie,
Samuel Ortiz, Lee Jones, Ji
In-Reply-To: <CALT56yP6K-sXOGM4z-WRsvFVjOi-13wM+Ewqn6WpDmNB4xcOEg@mail.gmail.com>
On Fri, Oct 31, 2014 at 6:58 PM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> 2014-10-31 12:52 GMT+03:00 Linus Walleij <linus.walleij@linaro.org>:
>> On Wed, Oct 29, 2014 at 4:03 AM, Alexandre Courbot <gnurou@gmail.com> wrote:
>>> On Tue, Oct 28, 2014 at 11:58 PM, Mark Brown <broonie@kernel.org> wrote:
>>>> On Tue, Oct 28, 2014 at 03:02:04AM +0300, Dmitry Eremin-Solenikov wrote:
>>>>> Since LoCoMo driver has been converted to provide proper gpiolib
>>>>> interface, make poodle ASoC platform driver use gpiolib API.
>>>>
>>>> Please use subject lines matching the style for the subsystem.
>>>>
>>>>> + ret = gpio_request_array(poodle_gpios, ARRAY_SIZE(poodle_gpios));
>>>>> + if (ret) {
>>>>> + dev_err(&pdev->dev, "gpio_request_array() failed: %d\n",
>>>>> + ret);
>>>>> + return ret;
>>>>> + }
>>>>
>>>> I sense a need for devm_gpio_request_array() here. Otherwise this looks
>>>> fine - ideally it'd move to gpiod but moving to gpiolib is a clear win
>>>> so no need to block on this.
>>>
>>> I wish Dmitry took the opportunity to move this driver to the gpiod
>>> API, especially since doing so would be trivial for this driver.
>>
>> +1 on this.
>>
>> However this platform is not device tree, so this implies setting up
>> a descriptor table for the affected driver(s) to work properly.
>> See Documentation/gpio/board.txt
>
> I checked the gpiod interfaces after original suggestion by Alexandre.
>
> Introducing those mapping tables (much like pinctrl tables) look like
> a duplicate effort if Russell will permit adding a DT support. So
> I thought that I will reconsider gpiod/pinctrl/etc after fixing
> LoCoMo, reiterating IRQ patches, possibly switching to COMMON_CLK
> and (finally) thinking about device tree support.
Note that the mapping tables are likely not going to end up being
huge, and taking that step will allow you to convert to the gpiod
interface, something you would probably want to do later when adding
DT support anyway. So at the end of the day there would be very little
wasted effort: once converting to DT, just add the GPIO properties
into the appropriate node, remove the mapping tables, and you're done.
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
From: Hans de Goede @ 2014-11-02 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKWqq+H5ymUW3n8tkmLJHEUGaKDLX5+orJmGUQ3ECQwUQ@mail.gmail.com>
Hi,
On 10/31/2014 09:47 PM, Rob Herring wrote:
> On Wed, Oct 29, 2014 at 7:08 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> Hi Hans, Rob,
>>
>> On 28/10/14 13:30, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 10/28/2014 12:11 PM, Rob Herring wrote:
>>
>>>> Yes, I object to the binding still as it has not changed from what was
>>>> previously posted.
>>>
>>> It would be helpful if you could explain why you object. Last time you
>>> said: " You are mixing in a hardware description that is simply inaccurate."
>>>
>>> I then explained that this is not hardware description, but runtime state
>>> information, as it tells the kernel which clocks were chosen to drive the
>>> display (out of typically a list of possible options, depending on which
>>> output is used, etc.). Just like which memory address the bootloader has
>>> chosen to scan out the video image from.
>>>
>>> Then you got quiet, so sorry, but this time your objection really is too
>>> late. You cannot simply go quiet halfway through a discussion and then pop
>>> up again when a new version is posted to say "I object" yet another time,
>>> you've had your chance to make your arguments last time, and chose to stay
>>> quiet after I explained in detail that this is not hardware description but
>>> state information, so now it is simply too late.
>>>
>>> These bindings have been discussed at Plumbers with various interested people
>>> present, and the conclusion was that this really is the best way to handle this,
>>> so this patch is:
>>>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>> Reviewed-by: Mike Turquette <mturquette@linaro.org>
>>> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
>>> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>>>
>>> And David Herrman who is working on simpledrm, which will be merged soon, which
>>> will also use the simplefb bindings also agrees. So we have the simplefb maintainer,
>>> simpledrm maintainer, and the clk subsystem maintainer + 2 other maintainers all
>>> agreeing on a way forward, the time for bikeshedding now really really really is
>>> over.
>>>
>>> Tomi, can you please let us know how you plan to proceed with this ?
>>
>> I won't merge DT bindings via fbdev tree, if a DT maintainer says no.
>>
>> I took Rob's silence to the earlier series as a silent ack for your
>> explanation. Obviously that was not the case.
>>
>> Rob, please advice asap what should be done to the bindings to get your
>> ack. As Hans explained above, this discussion has been going on for a
>> long time, and afaik this series is the best way forward of all the
>> options discussed.
>
> I still think for the most part this is a kernel problem. It is a
> kernel policy to turn off unused clocks. The clock framework could
> just as easily decide that any clocks enabled at boot and left
> un-managed (i.e. w/o a driver) are kept on until they are managed.
This is not just about being unmanaged, clocks can be shared, and another
driver can actively claim the clock and turn it off, we need to protect
against this too.
> I'm not saying this can't be in DT, only that DT is not the only solution
> here.
Basically the problem is that we must keep the clock enabled for the lifetime
of the simplefb device. We've been over this in 2 very long threads already,
and many alternatives have been evaluated and found wanting.
The only 100% safe way to ensure clocks are not turned off is to tie there
lifetime to that of the simplefb device, and the only reliable way to do
that is through a clocks property.
It really is that simple, and I don't understand why people keep insisting
there must be another way, while they fail to offer a (reliable, working)
other way.
> This problem is not unique to simplefb. A serial console could
> stop working if no serial driver is loaded before unused clocks are
> disabled. CPU core clocks have a similar issue as well (often enabled
> in platform code). I want to see this solved in a generic way for any
> clock.
>
> As regulators were also mentioned, they already have a
> "regulator-boot-on" property defined. Perhaps this is suitable to be
> mirrored for clocks. If it is not, then I'm wondering why we have it.
> A key difference here is that the property is part of the provider and
> can be dealt with in the clock driver rather than requiring a
> temporary driver.
"regulator-boot-on" tells the regulator framework to enable a regulator
at boot, but it does not protect it from getting turned of by another
driver later (it does not increase use_count).
So this is the same none solution as not turning off unmanaged clocks,
what if another driver who shares the clock, enables it during probe,
then disables it while done probing (to put things in low power state
until userspace uses the device).
This is not about not turning the clock off, this is about keeping
the clock on for the lifetime of the simplefb device, which is a different
problem, cause we must not remove a single calling point of clock_off,
put we must block all attempts to turn the clock off, which is done
by increasing its use-count, which is done by claiming + enabling it,
which needs a phandle to the clock ...
Regards,
Hans
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
From: jonsmirl @ 2014-11-02 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKWqq+H5ymUW3n8tkmLJHEUGaKDLX5+orJmGUQ3ECQwUQ@mail.gmail.com>
On Fri, Oct 31, 2014 at 4:47 PM, Rob Herring <robherring2@gmail.com> wrote:
>
> On Wed, Oct 29, 2014 at 7:08 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > Hi Hans, Rob,
> >
> > On 28/10/14 13:30, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 10/28/2014 12:11 PM, Rob Herring wrote:
> >
> >>> Yes, I object to the binding still as it has not changed from what was
> >>> previously posted.
> >>
> >> It would be helpful if you could explain why you object. Last time you
> >> said: " You are mixing in a hardware description that is simply inaccurate."
> >>
> >> I then explained that this is not hardware description, but runtime state
> >> information, as it tells the kernel which clocks were chosen to drive the
> >> display (out of typically a list of possible options, depending on which
> >> output is used, etc.). Just like which memory address the bootloader has
> >> chosen to scan out the video image from.
> >>
> >> Then you got quiet, so sorry, but this time your objection really is too
> >> late. You cannot simply go quiet halfway through a discussion and then pop
> >> up again when a new version is posted to say "I object" yet another time,
> >> you've had your chance to make your arguments last time, and chose to stay
> >> quiet after I explained in detail that this is not hardware description but
> >> state information, so now it is simply too late.
> >>
> >> These bindings have been discussed at Plumbers with various interested people
> >> present, and the conclusion was that this really is the best way to handle this,
> >> so this patch is:
> >>
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >> Reviewed-by: Mike Turquette <mturquette@linaro.org>
> >> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> >> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >>
> >> And David Herrman who is working on simpledrm, which will be merged soon, which
> >> will also use the simplefb bindings also agrees. So we have the simplefb maintainer,
> >> simpledrm maintainer, and the clk subsystem maintainer + 2 other maintainers all
> >> agreeing on a way forward, the time for bikeshedding now really really really is
> >> over.
> >>
> >> Tomi, can you please let us know how you plan to proceed with this ?
> >
> > I won't merge DT bindings via fbdev tree, if a DT maintainer says no.
> >
> > I took Rob's silence to the earlier series as a silent ack for your
> > explanation. Obviously that was not the case.
> >
> > Rob, please advice asap what should be done to the bindings to get your
> > ack. As Hans explained above, this discussion has been going on for a
> > long time, and afaik this series is the best way forward of all the
> > options discussed.
>
> I still think for the most part this is a kernel problem. It is a
> kernel policy to turn off unused clocks. The clock framework could
> just as easily decide that any clocks enabled at boot and left
> un-managed (i.e. w/o a driver) are kept on until they are managed. I'm
> not saying this can't be in DT, only that DT is not the only solution
> here. This problem is not unique to simplefb. A serial console could
> stop working if no serial driver is loaded before unused clocks are
> disabled. CPU core clocks have a similar issue as well (often enabled
> in platform code). I want to see this solved in a generic way for any
> clock.
I am in agreement this point of view. This is a problem in the Linux
kernel. It is not a generic problem.
The Linux problem is that during boot device drivers are loaded in two
phases - built-in and loadable modules. The clock-regulator clean up
is happening too early. It happens after the built-in drivers load and
before the loadable modules have a chance to load. That's simply the
wrong place for that clean up happen. A simple alternative would be
to make a tiny loadable module that triggers the clean up. Then adjust
your boot scripts to load this module after the other ones have
loaded. But instead of fixing this simple timing flaw in the Linux
boot process a complex mechanism is being created to work around it.
Simplefb is also being developed as a way of protecting the BIOS setup
of the framebuffer past the boot process and out into use as a normal
user space console. I in no way support this use. We have experienced
decades of problems on the x86 with VGA and BIOSes that I do not wish
to repeat in the ARM world. Write a correct, device specific
framebuffer driver for this piece of hardware. That device specific
driver will load before the clock/regulator cleanup and claim all of
the correct resources.
>
>
> As regulators were also mentioned, they already have a
> "regulator-boot-on" property defined. Perhaps this is suitable to be
> mirrored for clocks. If it is not, then I'm wondering why we have it.
> A key difference here is that the property is part of the provider and
> can be dealt with in the clock driver rather than requiring a
> temporary driver.
>
> Rob
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* (no subject)
From: MRS GRACE MANDA @ 2014-11-02 19:54 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1480763910.146593.1414958012342.JavaMail.yahoo@jws10033.mail.ne1.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 71 bytes --]
This is Mrs Grace Manda ( Please I need your Help is Urgent).
[-- Attachment #2: Mrs Grace Manda.rtf --]
[-- Type: application/rtf, Size: 35796 bytes --]
^ permalink raw reply
* Re: [PATCH 01/15] mfd: add new driver for Sharp LoCoMo
From: Linus Walleij @ 2014-11-03 13:41 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Input,
linux-leds-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org, Andrea Adami,
Russell King, Daniel Mack, Haojian Zhuang, Robert Jarzmik,
Alexandre Courbot, Dmitry Torokhov, Bryan Wu, Richard Purdie,
Samuel Ortiz, Lee Jones, Mark Brown, Jingoo
In-Reply-To: <CALT56yNX8v4mZn=o1ZoVLHPmg6wq0dgFNowpqNuFtU=eCc+d8w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Oct 31, 2014 at 10:54 AM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> 2014-10-31 10:42 GMT+03:00 Linus Walleij <linus.walleij@linaro.org>:
>> It seems some DAC handling is part of the MFD driver, and we recently
>> discussed that MFD should not be doing misc stuff but mainly act as
>> arbiter and switching station.
>>
>> Can you please move the DAC parts of the driver to
>> drivers/iio/dac?
>>
>> The IIO DAC subsystem will likely add other goodies to
>> the driver for free and give a nice API to consumers.
>
> I wanted this part to be as simple as possible. I will look into IIO
> DAC subsystem.
> The DAC is as simple 2 channel 8-bit i2c device connected to a separate i2c bus
> controlled through a register in LoCoMo device. One channel is used
> for backlight,
> other will be used for volume control. So (in theory) I can add the
> following device
> chain: locomo -> i2c-locomo -> m62332 -> IIO DAC client. However isn't that
> quite an overkill for just backlight & volume control? Please advice me on this.
The point is still the same: no unrelated code in drivers/mfd,
then either use IIO DAC as a middle layer or sink the DAC handling
into respective subdriver, i.e. push it into the backlight or
volume directly then.
>>> + /* Longtime timer */
>>> + writew(0, lchip->base + LOCOMO_LTINT);
>>> + /* SPI */
>>> + writew(0, lchip->base + LOCOMO_SPI + LOCOMO_SPIIE);
>>> +
>>> + writew(6 + 8 + 320 + 30 - 10, lchip->base + LOCOMO_ASD);
>>
>> That's a few magic numbers and calculation don't you think?
>>
>> A comment stating what's going on would be helpful.
>
> Unfortunately little is known here - these values are c&p from old 2.4
> Lineo code.
> This part is related to generating synchronization pulses for accessing
> touchscreen.
OK we have to live with reverse engineering results, that's OK.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 02/15] GPIO: port LoCoMo gpio support from old driver
From: Linus Walleij @ 2014-11-03 13:43 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Input,
linux-leds-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org, Andrea Adami,
Russell King, Daniel Mack, Haojian Zhuang, Robert Jarzmik,
Alexandre Courbot, Dmitry Torokhov, Bryan Wu, Richard Purdie,
Samuel Ortiz, Lee Jones, Mark Brown, Jingoo
In-Reply-To: <CALT56yOgMUA7o2dzfHph=S2zkDV4zERzMh4ishpPwpAx7Cqj6Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Oct 31, 2014 at 10:39 AM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> 2014-10-31 10:48 GMT+03:00 Linus Walleij <linus.walleij@linaro.org>:
>> On Tue, Oct 28, 2014 at 1:01 AM, Dmitry Eremin-Solenikov
>> <dbaryshkov@gmail.com> wrote:
>>
>>> Add gpiolib driver for gpio pins placed on the LoCoMo GA.
>>>
>>> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>>
>
> [skipped]
>
>> (etc, everywhere this pattern occurs).
>>> +static void locomo_gpio_set(struct gpio_chip *chip,
>>> + unsigned offset, int value)
>>> +{
>>> + struct locomo_gpio *lg = container_of(chip, struct locomo_gpio, gpio);
>>> + unsigned long flags;
>>> +
>>> + spin_lock_irqsave(&lg->lock, flags);
>>> +
>>> + __locomo_gpio_set(chip, offset, value);
>>> +
>>> + spin_unlock_irqrestore(&lg->lock, flags);
>>
>> If you actually always have to be getting and releasing a spin lock around
>> the register writes, contemplate using regmap-mmio because that
>> is part of what it does.
>>
>> But is this locking really necessary?
>
> I have a custom of doing such locking and never having to think about
> somebody breaking into RMW cycles.
>
> Also isn't regmap an overkill here? Wouldn't regmap also do a lock/unlock
> around each register read/write/RMW?
Yes that's the point: if you use regmap mmio you get the RMW-locking
for free, with the regmap implementation.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/4] omapdss: Add video output support for gta04 board
From: Marek Belisko @ 2014-11-03 21:59 UTC (permalink / raw)
To: linux-arm-kernel
This patch series add support for video output on gta04 board. It consist
from opa362 video amplifier driver + DT bindings, adding venc -> opa362 -> svideo-connecor
setup in DT and finally static setup for tvbypass anc acbias bin in devconf1 register
via pinctrl subsystem.
Marek Belisko (4):
video: omapdss: Add opa362 driver
Documentation: DT: Add documentation for ti,opa362 bindings
arm: dts: omap3-gta04: Add handling for tv output
arm: dts: omap3-gta04: Add static configuration for devconf1 register
.../devicetree/bindings/video/ti,opa362.txt | 38 +++
arch/arm/boot/dts/omap3-gta04.dtsi | 70 +++++
drivers/video/fbdev/omap2/displays-new/Kconfig | 6 +
drivers/video/fbdev/omap2/displays-new/Makefile | 1 +
.../fbdev/omap2/displays-new/amplifier-opa362.c | 347 +++++++++++++++++++++
5 files changed, 462 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,opa362.txt
create mode 100644 drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
--
1.9.1
^ permalink raw reply
* [PATCH 1/4] video: omapdss: Add opa362 driver
From: Marek Belisko @ 2014-11-03 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1415051968-4878-1-git-send-email-marek@goldelico.com>
opa362 is amplifier for videoand can be connected to the tvout pads
of the OMAP3. It has one gpio control for enable/disable of the output
(high impedance).
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
drivers/video/fbdev/omap2/displays-new/Kconfig | 6 +
drivers/video/fbdev/omap2/displays-new/Makefile | 1 +
.../fbdev/omap2/displays-new/amplifier-opa362.c | 347 +++++++++++++++++++++
3 files changed, 354 insertions(+)
create mode 100644 drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
diff --git a/drivers/video/fbdev/omap2/displays-new/Kconfig b/drivers/video/fbdev/omap2/displays-new/Kconfig
index e6cfc38..211b3ec 100644
--- a/drivers/video/fbdev/omap2/displays-new/Kconfig
+++ b/drivers/video/fbdev/omap2/displays-new/Kconfig
@@ -1,6 +1,12 @@
menu "OMAP Display Device Drivers (new device model)"
depends on OMAP2_DSS
+config DISPLAY_AMPLIFIER_OPA362
+ tristate "external analog amplifier with output disable/high-Z (e.g. OPA362)"
+ help
+ Driver to enable an external analog TV amplifier (e.g. OPA362)
+ through a GPIO.
+
config DISPLAY_ENCODER_TFP410
tristate "TFP410 DPI to DVI Encoder"
help
diff --git a/drivers/video/fbdev/omap2/displays-new/Makefile b/drivers/video/fbdev/omap2/displays-new/Makefile
index 0323a8a..b311542 100644
--- a/drivers/video/fbdev/omap2/displays-new/Makefile
+++ b/drivers/video/fbdev/omap2/displays-new/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_DISPLAY_AMPLIFIER_OPA362) += amplifier-opa362.o
obj-$(CONFIG_DISPLAY_ENCODER_TFP410) += encoder-tfp410.o
obj-$(CONFIG_DISPLAY_ENCODER_TPD12S015) += encoder-tpd12s015.o
obj-$(CONFIG_DISPLAY_CONNECTOR_DVI) += connector-dvi.o
diff --git a/drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c b/drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
new file mode 100644
index 0000000..37b2443
--- /dev/null
+++ b/drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
@@ -0,0 +1,347 @@
+/*
+ * OPA362 analog video amplifier with output/power control
+ *
+ * Copyright (C) 2014 Golden Delicious Computers
+ * Author: H. Nikolaus Schaller <hns@goldelico.com>
+ *
+ * based on encoder-tfp410
+ *
+ * Copyright (C) 2013 Texas Instruments
+ * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include <linux/gpio.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/of_gpio.h>
+
+#include <video/omapdss.h>
+#include <video/omap-panel-data.h>
+
+struct panel_drv_data {
+ struct omap_dss_device dssdev;
+ struct omap_dss_device *in;
+
+ int enable_gpio;
+ bool bypass;
+ bool acbias;
+
+ struct omap_video_timings timings;
+};
+
+#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
+
+static int opa362_connect(struct omap_dss_device *dssdev,
+ struct omap_dss_device *dst)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+ int r;
+
+ dev_dbg(dssdev->dev, "connect\n");
+
+ if (omapdss_device_is_connected(dssdev))
+ return -EBUSY;
+
+ r = in->ops.atv->connect(in, dssdev);
+ if (r)
+ return r;
+
+ dst->src = dssdev;
+ dssdev->dst = dst;
+
+ return 0;
+}
+
+static void opa362_disconnect(struct omap_dss_device *dssdev,
+ struct omap_dss_device *dst)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+
+ dev_dbg(dssdev->dev, "disconnect\n");
+
+ WARN_ON(!omapdss_device_is_connected(dssdev));
+ if (!omapdss_device_is_connected(dssdev))
+ return;
+
+ WARN_ON(dst != dssdev->dst);
+ if (dst != dssdev->dst)
+ return;
+
+ dst->src = NULL;
+ dssdev->dst = NULL;
+
+ in->ops.atv->disconnect(in, &ddata->dssdev);
+}
+
+static int opa362_enable(struct omap_dss_device *dssdev)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+ int r;
+
+ dev_dbg(dssdev->dev, "enable\n");
+
+ if (!omapdss_device_is_connected(dssdev))
+ return -ENODEV;
+
+ if (omapdss_device_is_enabled(dssdev))
+ return 0;
+
+ in->ops.atv->set_timings(in, &ddata->timings);
+ /* fixme: should we receive the invert from our consumer, i.e. the connector? */
+ in->ops.atv->invert_vid_out_polarity(in, true);
+
+ r = in->ops.atv->enable(in);
+ if (r)
+ return r;
+
+ if (gpio_is_valid(ddata->enable_gpio))
+ gpio_set_value_cansleep(ddata->enable_gpio, 1);
+
+ dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
+
+ return 0;
+}
+
+static void opa362_disable(struct omap_dss_device *dssdev)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+
+ dev_dbg(dssdev->dev, "disable\n");
+
+ if (!omapdss_device_is_enabled(dssdev))
+ return;
+
+ if (gpio_is_valid(ddata->enable_gpio))
+ gpio_set_value_cansleep(ddata->enable_gpio, 0);
+
+ in->ops.atv->disable(in);
+
+ dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
+}
+
+static void opa362_set_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+
+ dev_dbg(dssdev->dev, "set_timings\n");
+
+ ddata->timings = *timings;
+ dssdev->panel.timings = *timings;
+
+ in->ops.atv->set_timings(in, timings);
+}
+
+static void opa362_get_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+
+ dev_dbg(dssdev->dev, "get_timings\n");
+
+ *timings = ddata->timings;
+}
+
+static int opa362_check_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+
+ dev_dbg(dssdev->dev, "check_timings\n");
+
+ return in->ops.atv->check_timings(in, timings);
+}
+
+static void opa362_set_type(struct omap_dss_device *dssdev,
+ enum omap_dss_venc_type type)
+{
+ /* we can only drive a COMPOSITE output */
+ WARN_ON(type != OMAP_DSS_VENC_TYPE_COMPOSITE);
+
+}
+
+static void opa362_invert_vid_out_polarity(struct omap_dss_device *dssdev,
+ bool invert_polarity)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+
+ /* OPA362 inverts the polarity */
+ in->ops.atv->invert_vid_out_polarity(in, !invert_polarity);
+}
+
+static const struct omapdss_atv_ops opa362_atv_ops = {
+ .connect = opa362_connect,
+ .disconnect = opa362_disconnect,
+
+ .enable = opa362_enable,
+ .disable = opa362_disable,
+
+ .check_timings = opa362_check_timings,
+ .set_timings = opa362_set_timings,
+ .get_timings = opa362_get_timings,
+
+ .set_type = opa362_set_type,
+ .invert_vid_out_polarity = opa362_invert_vid_out_polarity,
+};
+
+static int opa362_probe_pdata(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct amplifier_opa362_platform_data *pdata;
+ struct omap_dss_device *dssdev, *in;
+
+ pdata = dev_get_platdata(&pdev->dev);
+
+ ddata->enable_gpio = pdata->enable_gpio;
+ ddata->bypass = pdata->bypass;
+ ddata->acbias = pdata->acbias;
+
+ in = omap_dss_find_output(pdata->source);
+ if (in = NULL) {
+ dev_err(&pdev->dev, "Failed to find video source\n");
+ return -ENODEV;
+ }
+
+ ddata->in = in;
+
+ dssdev = &ddata->dssdev;
+ dssdev->name = pdata->name;
+
+ return 0;
+}
+
+static int opa362_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+ int gpio;
+
+ gpio = of_get_gpio(node, 0);
+
+ if (gpio_is_valid(gpio) || gpio = -ENOENT) {
+ ddata->enable_gpio = gpio;
+ } else {
+ dev_err(&pdev->dev, "failed to parse enable gpio\n");
+ return gpio;
+ }
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ return 0;
+}
+
+static int opa362_probe(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata;
+ struct omap_dss_device *dssdev;
+ int r;
+
+ dev_dbg(&pdev->dev, "probe\n");
+
+ ddata = devm_kzalloc(&pdev->dev, sizeof(*ddata), GFP_KERNEL);
+ if (!ddata)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, ddata);
+
+ if (dev_get_platdata(&pdev->dev)) {
+ r = opa362_probe_pdata(pdev);
+ if (r)
+ return r;
+ } else {
+ r = opa362_probe_of(pdev);
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(ddata->enable_gpio)) {
+ r = devm_gpio_request_one(&pdev->dev, ddata->enable_gpio,
+ GPIOF_OUT_INIT_LOW, "opa362 enable");
+ if (r) {
+ dev_err(&pdev->dev, "Failed to request enable GPIO %d\n",
+ ddata->enable_gpio);
+ goto err_gpio;
+ }
+ }
+
+ dssdev = &ddata->dssdev;
+ dssdev->ops.atv = &opa362_atv_ops;
+ dssdev->dev = &pdev->dev;
+ dssdev->type = OMAP_DISPLAY_TYPE_VENC;
+ dssdev->output_type = OMAP_DISPLAY_TYPE_VENC;
+ dssdev->owner = THIS_MODULE;
+
+ r = omapdss_register_output(dssdev);
+ if (r) {
+ dev_err(&pdev->dev, "Failed to register output\n");
+ goto err_reg;
+ }
+
+ return 0;
+err_reg:
+err_gpio:
+ omap_dss_put_device(ddata->in);
+ return r;
+}
+
+static int __exit opa362_remove(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct omap_dss_device *dssdev = &ddata->dssdev;
+ struct omap_dss_device *in = ddata->in;
+
+ omapdss_unregister_output(&ddata->dssdev);
+
+ WARN_ON(omapdss_device_is_enabled(dssdev));
+ if (omapdss_device_is_enabled(dssdev))
+ opa362_disable(dssdev);
+
+ WARN_ON(omapdss_device_is_connected(dssdev));
+ if (omapdss_device_is_connected(dssdev))
+ opa362_disconnect(dssdev, dssdev->dst);
+
+ omap_dss_put_device(in);
+
+ return 0;
+}
+
+static const struct of_device_id opa362_of_match[] = {
+ { .compatible = "omapdss,ti,opa362", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, opa362_of_match);
+
+static struct platform_driver opa362_driver = {
+ .probe = opa362_probe,
+ .remove = __exit_p(opa362_remove),
+ .driver = {
+ .name = "amplifier-opa362",
+ .owner = THIS_MODULE,
+ .of_match_table = opa362_of_match,
+ },
+};
+
+module_platform_driver(opa362_driver);
+
+MODULE_AUTHOR("H. Nikolaus Schaller <hns@goldelico.com>");
+MODULE_DESCRIPTION("OPA362 analog video amplifier with output/power control");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] Documentation: DT: Add documentation for ti,opa362 bindings
From: Marek Belisko @ 2014-11-03 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1415051968-4878-1-git-send-email-marek@goldelico.com>
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
.../devicetree/bindings/video/ti,opa362.txt | 38 ++++++++++++++++++++++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,opa362.txt
diff --git a/Documentation/devicetree/bindings/video/ti,opa362.txt b/Documentation/devicetree/bindings/video/ti,opa362.txt
new file mode 100644
index 0000000..d7ed11a
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,opa362.txt
@@ -0,0 +1,38 @@
+OPA362 analog video amplifier
+
+Required properties:
+- compatible: "ti,opa362"
+- gpio: enable/disable output gpio
+
+Required node:
+- Video port 0 for opa362 input
+- Video port 1 for opa362 output
+
+Example:
+
+tv_amp: opa362 {
+ compatible = "ti,opa362";
+ gpios = <&gpio1 23 0>; /* GPIO to enable video out amplifier */
+
+ label = "opa362";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ opa_in: endpoint@0 {
+ remote-endpoint = <&venc_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ opa_out: endpoint@0 {
+ remote-endpoint = <&tv_connector_in>;
+ };
+ };
+ };
+ };
+
+
+
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] arm: dts: omap3-gta04: Add handling for tv output
From: Marek Belisko @ 2014-11-03 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1415051968-4878-1-git-send-email-marek@goldelico.com>
Add handling for gta04 tv out chain:
venc -> opa362 -> svideo
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
arch/arm/boot/dts/omap3-gta04.dtsi | 48 ++++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index fd34f91..e4d05f0 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -83,6 +83,41 @@
compatible = "usb-nop-xceiv";
reset-gpios = <&gpio6 14 GPIO_ACTIVE_LOW>;
};
+
+ tv0: connector@1 {
+ compatible = "svideo-connector";
+ label = "tv";
+
+ port {
+ tv_connector_in: endpoint {
+ remote-endpoint = <&opa_out>;
+ };
+ };
+ };
+
+ tv_amp: opa362 {
+ compatible = "ti,opa362";
+ gpios = <&gpio1 23 0>;
+
+ label = "opa362";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ opa_in: endpoint@0 {
+ remote-endpoint = <&venc_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ opa_out: endpoint@0 {
+ remote-endpoint = <&tv_connector_in>;
+ };
+ };
+ };
+ };
};
&omap3_pmx_core {
@@ -396,6 +431,19 @@
};
};
+&venc {
+ status = "okay";
+
+ vdda-supply = <&vdac>;
+
+ port {
+ venc_out: endpoint {
+ remote-endpoint = <&opa_in>;
+ ti,channels = <2>;
+ };
+ };
+};
+
&gpmc {
ranges = <0 0 0x30000000 0x04>; /* CS0: NAND */
--
1.9.1
^ permalink raw reply related
* [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
From: Marek Belisko @ 2014-11-03 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1415051968-4878-1-git-send-email-marek@goldelico.com>
gta04 board need for tvout enabled 2 bits in devconf1 register (tvbypass and acbias).
Add single pinmux entry and enable it.
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
arch/arm/boot/dts/omap3-gta04.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index e4d05f0..a456d37 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -118,6 +118,17 @@
};
};
};
+
+ /* pinmux for devconf1 */
+ control_devconf1: pinmux@480022d8 {
+ compatible = "pinctrl-single";
+ reg = <0x480022d8 4>; /* single register */
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0xfc0bd5>;
+ };
};
&omap3_pmx_core {
@@ -497,3 +508,14 @@
};
};
};
+
+&control_devconf1 {
+ pinctrl-name = "default";
+ pinctrl-0 = < &tv_acbias_pins>;
+
+ tv_acbias_pins: pinmux_tv_acbias_pins {
+ pinctrl-single,bits = <
+ 0 0x40800 0x40800
+ >;
+ };
+};
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v4 0/5] simplefb: add clock handling code
From: Luc Verhaegen @ 2014-11-05 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4Oyw46zjq8QJNAFi9qWA9-6MpXtGavzVmXQT3SPqH=NpjQ@mail.gmail.com>
On Sun, Nov 02, 2014 at 10:28:48AM -0500, jonsmirl@gmail.com wrote:
>
> Simplefb is also being developed as a way of protecting the BIOS setup
> of the framebuffer past the boot process and out into use as a normal
> user space console. I in no way support this use. We have experienced
> decades of problems on the x86 with VGA and BIOSes that I do not wish
> to repeat in the ARM world.
Oh wow.
Luc Verhaegen, aka, the guy who made BIOS-free display drivers possible.
^ permalink raw reply
* Re: [PATCH 01/15] mfd: add new driver for Sharp LoCoMo
From: Dmitry Eremin-Solenikov @ 2014-11-05 20:02 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
Linux Input, linux-leds@vger.kernel.org,
linux-spi@vger.kernel.org, linux-fbdev@vger.kernel.org,
alsa-devel@alsa-project.org, Andrea Adami, Russell King,
Daniel Mack, Haojian Zhuang, Robert Jarzmik, Alexandre Courbot,
Dmitry Torokhov, Bryan Wu, Richard Purdie, Samuel Ortiz,
Lee Jones, Mark Brown, Jingoo
In-Reply-To: <CACRpkdaKUZjbSEH75M9xudTF9HefwOCVEe5otv9-9f2UG8=hVg@mail.gmail.com>
2014-11-03 16:41 GMT+03:00 Linus Walleij <linus.walleij@linaro.org>:
> On Fri, Oct 31, 2014 at 10:54 AM, Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com> wrote:
>> 2014-10-31 10:42 GMT+03:00 Linus Walleij <linus.walleij@linaro.org>:
>
>>> It seems some DAC handling is part of the MFD driver, and we recently
>>> discussed that MFD should not be doing misc stuff but mainly act as
>>> arbiter and switching station.
>>>
>>> Can you please move the DAC parts of the driver to
>>> drivers/iio/dac?
>>>
>>> The IIO DAC subsystem will likely add other goodies to
>>> the driver for free and give a nice API to consumers.
>>
>> I wanted this part to be as simple as possible. I will look into IIO
>> DAC subsystem.
>> The DAC is as simple 2 channel 8-bit i2c device connected to a separate i2c bus
>> controlled through a register in LoCoMo device. One channel is used
>> for backlight,
>> other will be used for volume control. So (in theory) I can add the
>> following device
>> chain: locomo -> i2c-locomo -> m62332 -> IIO DAC client. However isn't that
>> quite an overkill for just backlight & volume control? Please advice me on this.
>
> The point is still the same: no unrelated code in drivers/mfd,
> then either use IIO DAC as a middle layer or sink the DAC handling
> into respective subdriver, i.e. push it into the backlight or
> volume directly then.
The problem is that the DAC is equally used by backlight and by sound
device (WIP).
What about true i2c device driver sitting in drivers/misc and exporting a regmap
of 2 8-bit registers?
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 01/15] mfd: add new driver for Sharp LoCoMo
From: Mark Brown @ 2014-11-05 20:24 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: Linus Walleij, linux-arm-kernel@lists.infradead.org,
linux-gpio@vger.kernel.org, Linux Input,
linux-leds@vger.kernel.org, linux-spi@vger.kernel.org,
linux-fbdev@vger.kernel.org, alsa-devel@alsa-project.org,
Andrea Adami, Russell King, Daniel Mack, Haojian Zhuang,
Robert Jarzmik, Alexandre Courbot, Dmitry Torokhov, Bryan Wu,
Richard Purdie, Samuel Ortiz, Lee Jones
In-Reply-To: <CALT56yM8B3ffYb0=EZVbRRGDZSxMci2sRp9XVtjQuLa5abN+cg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 720 bytes --]
On Thu, Nov 06, 2014 at 12:02:49AM +0400, Dmitry Eremin-Solenikov wrote:
> 2014-11-03 16:41 GMT+03:00 Linus Walleij <linus.walleij@linaro.org>:
> > The point is still the same: no unrelated code in drivers/mfd,
> > then either use IIO DAC as a middle layer or sink the DAC handling
> > into respective subdriver, i.e. push it into the backlight or
> > volume directly then.
> The problem is that the DAC is equally used by backlight and by sound
> device (WIP).
> What about true i2c device driver sitting in drivers/misc and exporting a regmap
> of 2 8-bit registers?
If it can just export registers that sounds like a MFD. If it needs to
export functionality then like Linus says the IIO subsystem abstracts
DACs.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH 01/15] mfd: add new driver for Sharp LoCoMo
From: Lars-Peter Clausen @ 2014-11-05 20:32 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov, Linus Walleij
Cc: Alexandre Courbot, linux-fbdev@vger.kernel.org, Bryan Wu,
Russell King, Samuel Ortiz, Liam Girdwood, Lee Jones,
Dmitry Torokhov, alsa-devel@alsa-project.org, Haojian Zhuang,
linux-spi@vger.kernel.org, linux-gpio@vger.kernel.org, Mark Brown,
Andrea Adami, linux-arm-kernel@lists.infradead.org, Linux Input,
Jingoo Han, Daniel Mack, Robert Jarzmik, Richard Purdie
In-Reply-To: <CALT56yM8B3ffYb0=EZVbRRGDZSxMci2sRp9XVtjQuLa5abN+cg@mail.gmail.com>
On 11/05/2014 09:02 PM, Dmitry Eremin-Solenikov wrote:
> 2014-11-03 16:41 GMT+03:00 Linus Walleij <linus.walleij@linaro.org>:
>> On Fri, Oct 31, 2014 at 10:54 AM, Dmitry Eremin-Solenikov
>> <dbaryshkov@gmail.com> wrote:
>>> 2014-10-31 10:42 GMT+03:00 Linus Walleij <linus.walleij@linaro.org>:
>>
>>>> It seems some DAC handling is part of the MFD driver, and we recently
>>>> discussed that MFD should not be doing misc stuff but mainly act as
>>>> arbiter and switching station.
>>>>
>>>> Can you please move the DAC parts of the driver to
>>>> drivers/iio/dac?
>>>>
>>>> The IIO DAC subsystem will likely add other goodies to
>>>> the driver for free and give a nice API to consumers.
>>>
>>> I wanted this part to be as simple as possible. I will look into IIO
>>> DAC subsystem.
>>> The DAC is as simple 2 channel 8-bit i2c device connected to a separate i2c bus
>>> controlled through a register in LoCoMo device. One channel is used
>>> for backlight,
>>> other will be used for volume control. So (in theory) I can add the
>>> following device
>>> chain: locomo -> i2c-locomo -> m62332 -> IIO DAC client. However isn't that
>>> quite an overkill for just backlight & volume control? Please advice me on this.
>>
>> The point is still the same: no unrelated code in drivers/mfd,
>> then either use IIO DAC as a middle layer or sink the DAC handling
>> into respective subdriver, i.e. push it into the backlight or
>> volume directly then.
>
> The problem is that the DAC is equally used by backlight and by sound
> device (WIP).
That shouldn't be a problem. The IIO API allows different consumers to
request different channels of a converter. You can write a generic IIO based
backlight driver and a generic IIO based volume control driver. This makes
it possible to re-use them in other circuits with other DACs but the same
application.
> What about true i2c device driver sitting in drivers/misc and exporting a regmap
> of 2 8-bit registers?
If it is a generic DAC it should go into drivers/iio/, this will allow code
sharing and code re-usability. Given the simplicity of the DAC there might
even be other existing drivers that can be used to control it.
- Lars
^ permalink raw reply
* Re: [PATCH 01/15] mfd: add new driver for Sharp LoCoMo
From: Lars-Peter Clausen @ 2014-11-05 20:42 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov, Linus Walleij
Cc: linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
Linux Input, linux-leds@vger.kernel.org,
linux-spi@vger.kernel.org, linux-fbdev@vger.kernel.org,
alsa-devel@alsa-project.org, Andrea Adami, Russell King,
Daniel Mack, Haojian Zhuang, Robert Jarzmik, Alexandre Courbot,
Dmitry Torokhov, Bryan Wu, Richard Purdie, Samuel Ortiz,
Lee Jones, Mark Brown, Jingoo
In-Reply-To: <545A8965.2010406@metafoo.de>
On 11/05/2014 09:32 PM, Lars-Peter Clausen wrote:
> If it is a generic DAC it should go into drivers/iio/, this will allow code
> sharing and code re-usability. Given the simplicity of the DAC there might
> even be other existing drivers that can be used to control it.
I just had a quick look and I think the M62332 will work out of the box with
the max517 driver.
- Lars
^ permalink raw reply
* Re: [PATCH 02/15] GPIO: port LoCoMo gpio support from old driver
From: Dmitry Eremin-Solenikov @ 2014-11-05 21:33 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Input,
linux-leds-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org, Andrea Adami,
Russell King, Daniel Mack, Haojian Zhuang, Robert Jarzmik,
Alexandre Courbot, Dmitry Torokhov, Bryan Wu, Richard Purdie,
Samuel Ortiz, Lee Jones, Mark Brown, Jingoo
In-Reply-To: <CACRpkdb7v3LmOhbhQ9TPk1_bnLnpwizawW6RQvhQRLSjRewAaQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-03 16:43 GMT+03:00 Linus Walleij <linus.walleij@linaro.org>:
> On Fri, Oct 31, 2014 at 10:39 AM, Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com> wrote:
>> 2014-10-31 10:48 GMT+03:00 Linus Walleij <linus.walleij@linaro.org>:
>>> On Tue, Oct 28, 2014 at 1:01 AM, Dmitry Eremin-Solenikov
>>> <dbaryshkov@gmail.com> wrote:
>>>
>>>> Add gpiolib driver for gpio pins placed on the LoCoMo GA.
>>>>
>>>> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>>>
>>
>> [skipped]
>>
>>> (etc, everywhere this pattern occurs).
>>>> +static void locomo_gpio_set(struct gpio_chip *chip,
>>>> + unsigned offset, int value)
>>>> +{
>>>> + struct locomo_gpio *lg = container_of(chip, struct locomo_gpio, gpio);
>>>> + unsigned long flags;
>>>> +
>>>> + spin_lock_irqsave(&lg->lock, flags);
>>>> +
>>>> + __locomo_gpio_set(chip, offset, value);
>>>> +
>>>> + spin_unlock_irqrestore(&lg->lock, flags);
>>>
>>> If you actually always have to be getting and releasing a spin lock around
>>> the register writes, contemplate using regmap-mmio because that
>>> is part of what it does.
>>>
>>> But is this locking really necessary?
>>
>> I have a custom of doing such locking and never having to think about
>> somebody breaking into RMW cycles.
>>
>> Also isn't regmap an overkill here? Wouldn't regmap also do a lock/unlock
>> around each register read/write/RMW?
>
> Yes that's the point: if you use regmap mmio you get the RMW-locking
> for free, with the regmap implementation.
Just to be more concrete. Currently locomo_gpio_ack_irq() function uses
one lock and one unlock for doing 3 consecutive RMW I I convert locomo
to regmap, will that be 3 lock/unlock calls or still one? (Or maybe I'm
trying to be over-protective here and adding more lock/unlock cycles
won't matter that much?)
Next question: if I have to export regmap to several subdrivers, is it better
to have one big regmap or to have one-map-per-driver approach?
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 02/15] GPIO: port LoCoMo gpio support from old driver
From: Mark Brown @ 2014-11-06 6:03 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: Linus Walleij, linux-arm-kernel@lists.infradead.org,
linux-gpio@vger.kernel.org, Linux Input,
linux-leds@vger.kernel.org, linux-spi@vger.kernel.org,
linux-fbdev@vger.kernel.org, alsa-devel@alsa-project.org,
Andrea Adami, Russell King, Daniel Mack, Haojian Zhuang,
Robert Jarzmik, Alexandre Courbot, Dmitry Torokhov, Bryan Wu,
Richard Purdie, Samuel Ortiz, Lee Jones
In-Reply-To: <CALT56yO9f8wzaArnmfQSDzCM3S+2oT+62anH5kbFY3WdEt_HZg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 927 bytes --]
On Thu, Nov 06, 2014 at 01:33:24AM +0400, Dmitry Eremin-Solenikov wrote:
> 2014-11-03 16:43 GMT+03:00 Linus Walleij <linus.walleij@linaro.org>:
> > Yes that's the point: if you use regmap mmio you get the RMW-locking
> > for free, with the regmap implementation.
> Just to be more concrete. Currently locomo_gpio_ack_irq() function uses
> one lock and one unlock for doing 3 consecutive RMW I I convert locomo
> to regmap, will that be 3 lock/unlock calls or still one? (Or maybe I'm
> trying to be over-protective here and adding more lock/unlock cycles
> won't matter that much?)
You'll get three lock/unlocks, we could add an interface for bulk
updates under one lock if it's important though.
> Next question: if I have to export regmap to several subdrivers, is it better
> to have one big regmap or to have one-map-per-driver approach?
One regmap for the physical register map which is shared between all the
users.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* [PATCH RESEND 0/5] arm: sa1100: add cpu clock for fbdev and pcmcia
From: Dmitry Eremin-Solenikov @ 2014-11-06 7:41 UTC (permalink / raw)
To: linux-fbdev
These patches are required to make SL-5500 (collie) to work properly.
Framebuffer maintainer added his ack to the respective patch. PCMCIA
subsystem seems to be unmaintained at this moment. Russell, could you
please review and hopefully ack these patches?
On SA-1100 framebuffer and PCMCIA drivers make use of cpufreq_get(0)
function call to determine the cpu frequency. Russell's commit
1937f5b91833e2e8e53bcc821fc7a5fbe6ccb9b5 (ARM: fix sa1100 build) fixed
the build issues, but broke two devices (Collie and Jornada720). For
those two boards the cpufreq code gets compiled but is not enabled (as
board files do not provide timing information for the CPUFREQ driver).
Thus cpufreq_get(0) returns incorrect value and incorrect timings get
programmed into the hardware.
PXA2xx (the very similar platform) uses Clock API to determine CPU
frequency both in framebuffer and PCMCIA drivers. These patches make
similar changes to StrongARM drivers.
^ permalink raw reply
* [PATCH RESEND 1/5] arm: sa1100: add cpu clock
From: Dmitry Eremin-Solenikov @ 2014-11-06 7:41 UTC (permalink / raw)
To: linux-fbdev
Both SA1100 framebuffer and PCMCIA drivers require knowledge of cpu
frequency to correctly program timings. Currently they receive timing
information by calling cpufreq_get(0). However if cpu frequency driver
is not enabled (e.g. due to unsupported DRAM chip/board on sa1110)
cpufreq_get(0) returns 0, causing incorrect timings to be programmed.
Add cpu clock returning cpu frequency, to be used by sa11x0 fb and
pcmcia drivers.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
arch/arm/mach-sa1100/clock.c | 41 ++++++++++++++++++++++++++++++++++-------
1 file changed, 34 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-sa1100/clock.c b/arch/arm/mach-sa1100/clock.c
index 9fa6a99..53f750d 100644
--- a/arch/arm/mach-sa1100/clock.c
+++ b/arch/arm/mach-sa1100/clock.c
@@ -15,10 +15,12 @@
#include <linux/clkdev.h>
#include <mach/hardware.h>
+#include <mach/generic.h>
struct clkops {
void (*enable)(struct clk *);
void (*disable)(struct clk *);
+ unsigned long (*get_rate)(struct clk *);
};
struct clk {
@@ -33,13 +35,6 @@ struct clk clk_##_name = { \
static DEFINE_SPINLOCK(clocks_lock);
-/* Dummy clk routine to build generic kernel parts that may be using them */
-unsigned long clk_get_rate(struct clk *clk)
-{
- return 0;
-}
-EXPORT_SYMBOL(clk_get_rate);
-
static void clk_gpio27_enable(struct clk *clk)
{
/*
@@ -58,6 +53,19 @@ static void clk_gpio27_disable(struct clk *clk)
GAFR &= ~GPIO_32_768kHz;
}
+static void clk_cpu_enable(struct clk *clk)
+{
+}
+
+static void clk_cpu_disable(struct clk *clk)
+{
+}
+
+static unsigned long clk_cpu_get_rate(struct clk *clk)
+{
+ return sa11x0_getspeed(0) * 1000;
+}
+
int clk_enable(struct clk *clk)
{
unsigned long flags;
@@ -87,16 +95,35 @@ void clk_disable(struct clk *clk)
}
EXPORT_SYMBOL(clk_disable);
+unsigned long clk_get_rate(struct clk *clk)
+{
+ if (clk && clk->ops && clk->ops->get_rate)
+ return clk->ops->get_rate(clk);
+
+ return 0;
+}
+EXPORT_SYMBOL(clk_get_rate);
+
const struct clkops clk_gpio27_ops = {
.enable = clk_gpio27_enable,
.disable = clk_gpio27_disable,
};
+const struct clkops clk_cpu_ops = {
+ .enable = clk_cpu_enable,
+ .disable = clk_cpu_disable,
+ .get_rate = clk_cpu_get_rate,
+};
+
static DEFINE_CLK(gpio27, &clk_gpio27_ops);
+static DEFINE_CLK(cpu, &clk_cpu_ops);
+
static struct clk_lookup sa11xx_clkregs[] = {
CLKDEV_INIT("sa1111.0", NULL, &clk_gpio27),
CLKDEV_INIT("sa1100-rtc", NULL, NULL),
+ CLKDEV_INIT("sa11x0-fb", NULL, &clk_cpu),
+ CLKDEV_INIT("sa11x0-pcmcia", NULL, &clk_cpu),
};
static int __init sa11xx_clk_init(void)
--
2.1.1
^ permalink raw reply related
* [PATCH RESEND 2/5] arm: sa1100: add a clock alias for sa1111 pcmcia device
From: Dmitry Eremin-Solenikov @ 2014-11-06 7:41 UTC (permalink / raw)
To: linux-fbdev
SA-1111 uses internal MMIO space offsets as a device name, so device
name for sa1111 pcmcia is 1800 (PCMCIA is at offset 0x1800).
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
arch/arm/mach-sa1100/clock.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-sa1100/clock.c b/arch/arm/mach-sa1100/clock.c
index 53f750d..03c75a8 100644
--- a/arch/arm/mach-sa1100/clock.c
+++ b/arch/arm/mach-sa1100/clock.c
@@ -124,6 +124,8 @@ static struct clk_lookup sa11xx_clkregs[] = {
CLKDEV_INIT("sa1100-rtc", NULL, NULL),
CLKDEV_INIT("sa11x0-fb", NULL, &clk_cpu),
CLKDEV_INIT("sa11x0-pcmcia", NULL, &clk_cpu),
+ /* sa1111 names devices using internal offsets, PCMCIA is at 0x1800 */
+ CLKDEV_INIT("1800", NULL, &clk_cpu),
};
static int __init sa11xx_clk_init(void)
--
2.1.1
^ permalink raw reply related
* [PATCH RESEND 3/5] fbdev: sa1100fb: make use of device clock
From: Dmitry Eremin-Solenikov @ 2014-11-06 7:41 UTC (permalink / raw)
To: linux-fbdev
Use per-device clock (instead of calling cpufreq_get(0), which can
return 0 if no cpu frequency driver is selected) to program timings.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/sa1100fb.c | 24 +++++++++++++++++-------
drivers/video/fbdev/sa1100fb.h | 1 +
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/sa1100fb.c b/drivers/video/fbdev/sa1100fb.c
index 580c444e..8933840 100644
--- a/drivers/video/fbdev/sa1100fb.c
+++ b/drivers/video/fbdev/sa1100fb.c
@@ -178,6 +178,7 @@
#include <linux/dma-mapping.h>
#include <linux/mutex.h>
#include <linux/io.h>
+#include <linux/clk.h>
#include <video/sa1100fb.h>
@@ -413,9 +414,9 @@ sa1100fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
var->transp.offset);
#ifdef CONFIG_CPU_FREQ
- dev_dbg(fbi->dev, "dma period = %d ps, clock = %d kHz\n",
+ dev_dbg(fbi->dev, "dma period = %d ps, clock = %ld kHz\n",
sa1100fb_display_dma_period(var),
- cpufreq_get(smp_processor_id()));
+ clk_get_rate(fbi->clk) / 1000);
#endif
return 0;
@@ -586,9 +587,10 @@ static struct fb_ops sa1100fb_ops = {
* Calculate the PCD value from the clock rate (in picoseconds).
* We take account of the PPCR clock setting.
*/
-static inline unsigned int get_pcd(unsigned int pixclock, unsigned int cpuclock)
+static inline unsigned int get_pcd(struct sa1100fb_info *fbi,
+ unsigned int pixclock)
{
- unsigned int pcd = cpuclock / 100;
+ unsigned int pcd = clk_get_rate(fbi->clk) / 100 / 1000;
pcd *= pixclock;
pcd /= 10000000;
@@ -667,7 +669,7 @@ static int sa1100fb_activate_var(struct fb_var_screeninfo *var, struct sa1100fb_
LCCR2_BegFrmDel(var->upper_margin) +
LCCR2_EndFrmDel(var->lower_margin);
- pcd = get_pcd(var->pixclock, cpufreq_get(0));
+ pcd = get_pcd(fbi, var->pixclock);
new_regs.lccr3 = LCCR3_PixClkDiv(pcd) | fbi->inf->lccr3 |
(var->sync & FB_SYNC_HOR_HIGH_ACT ? LCCR3_HorSnchH : LCCR3_HorSnchL) |
(var->sync & FB_SYNC_VERT_HIGH_ACT ? LCCR3_VrtSnchH : LCCR3_VrtSnchL);
@@ -1003,7 +1005,6 @@ sa1100fb_freq_transition(struct notifier_block *nb, unsigned long val,
void *data)
{
struct sa1100fb_info *fbi = TO_INF(nb, freq_transition);
- struct cpufreq_freqs *f = data;
u_int pcd;
switch (val) {
@@ -1012,7 +1013,7 @@ sa1100fb_freq_transition(struct notifier_block *nb, unsigned long val,
break;
case CPUFREQ_POSTCHANGE:
- pcd = get_pcd(fbi->fb.var.pixclock, f->new);
+ pcd = get_pcd(fbi, fbi->fb.var.pixclock);
fbi->reg_lccr3 = (fbi->reg_lccr3 & ~0xff) | LCCR3_PixClkDiv(pcd);
set_ctrlr_state(fbi, C_ENABLE_CLKCHANGE);
break;
@@ -1219,6 +1220,13 @@ static int sa1100fb_probe(struct platform_device *pdev)
if (!fbi)
goto failed;
+ fbi->clk = clk_get(&pdev->dev, NULL);
+ if (IS_ERR(fbi->clk)) {
+ ret = PTR_ERR(fbi->clk);
+ fbi->clk = NULL;
+ goto failed;
+ }
+
fbi->base = ioremap(res->start, resource_size(res));
if (!fbi->base)
goto failed;
@@ -1271,6 +1279,8 @@ static int sa1100fb_probe(struct platform_device *pdev)
failed:
if (fbi)
iounmap(fbi->base);
+ if (fbi->clk)
+ clk_put(fbi->clk);
kfree(fbi);
release_mem_region(res->start, resource_size(res));
return ret;
diff --git a/drivers/video/fbdev/sa1100fb.h b/drivers/video/fbdev/sa1100fb.h
index fc5d429..0139d13 100644
--- a/drivers/video/fbdev/sa1100fb.h
+++ b/drivers/video/fbdev/sa1100fb.h
@@ -68,6 +68,7 @@ struct sa1100fb_info {
#endif
const struct sa1100fb_mach_info *inf;
+ struct clk *clk;
};
#define TO_INF(ptr,member) container_of(ptr,struct sa1100fb_info,member)
--
2.1.1
^ permalink raw reply related
* [PATCH RESEND 4/5] pcmcia: sa1100: make use of device clock
From: Dmitry Eremin-Solenikov @ 2014-11-06 7:41 UTC (permalink / raw)
To: linux-fbdev
Use per-device clock (instead of calling cpufreq_get(0), which can
return 0 if no cpu frequency driver is selected) to program timings.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/pcmcia/sa1100_generic.c | 1 +
drivers/pcmcia/sa11xx_base.c | 14 ++++++++++++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/pcmcia/sa1100_generic.c b/drivers/pcmcia/sa1100_generic.c
index ff8a027..d2ab060 100644
--- a/drivers/pcmcia/sa1100_generic.c
+++ b/drivers/pcmcia/sa1100_generic.c
@@ -93,6 +93,7 @@ static int sa11x0_drv_pcmcia_remove(struct platform_device *dev)
for (i = 0; i < sinfo->nskt; i++)
soc_pcmcia_remove_one(&sinfo->skt[i]);
+ clk_put(sinfo->clk);
kfree(sinfo);
return 0;
}
diff --git a/drivers/pcmcia/sa11xx_base.c b/drivers/pcmcia/sa11xx_base.c
index 54d3089..6dd94bb 100644
--- a/drivers/pcmcia/sa11xx_base.c
+++ b/drivers/pcmcia/sa11xx_base.c
@@ -135,14 +135,16 @@ sa1100_pcmcia_frequency_change(struct soc_pcmcia_socket *skt,
static int
sa1100_pcmcia_set_timing(struct soc_pcmcia_socket *skt)
{
- return sa1100_pcmcia_set_mecr(skt, cpufreq_get(0));
+ unsigned long clk = clk_get_rate(skt->clk);
+
+ return sa1100_pcmcia_set_mecr(skt, clk / 1000);
}
static int
sa1100_pcmcia_show_timing(struct soc_pcmcia_socket *skt, char *buf)
{
struct soc_pcmcia_timing timing;
- unsigned int clock = cpufreq_get(0);
+ unsigned int clock = clk_get_rate(skt->clk);
unsigned long mecr = MECR;
char *p = buf;
@@ -218,6 +220,11 @@ int sa11xx_drv_pcmcia_probe(struct device *dev, struct pcmcia_low_level *ops,
struct skt_dev_info *sinfo;
struct soc_pcmcia_socket *skt;
int i, ret = 0;
+ struct clk *clk;
+
+ clk = clk_get(dev, NULL);
+ if (IS_ERR(clk))
+ return -ENODEV;
sa11xx_drv_pcmcia_ops(ops);
@@ -226,12 +233,14 @@ int sa11xx_drv_pcmcia_probe(struct device *dev, struct pcmcia_low_level *ops,
return -ENOMEM;
sinfo->nskt = nr;
+ sinfo->clk = clk;
/* Initialize processor specific parameters */
for (i = 0; i < nr; i++) {
skt = &sinfo->skt[i];
skt->nr = first + i;
+ skt->clk = clk;
soc_pcmcia_init_one(skt, ops, dev);
ret = sa11xx_drv_pcmcia_add_one(skt);
@@ -242,6 +251,7 @@ int sa11xx_drv_pcmcia_probe(struct device *dev, struct pcmcia_low_level *ops,
if (ret) {
while (--i >= 0)
soc_pcmcia_remove_one(&sinfo->skt[i]);
+ clk_put(clk);
kfree(sinfo);
} else {
dev_set_drvdata(dev, sinfo);
--
2.1.1
^ permalink raw reply related
* [PATCH RESEND 5/5] pcmcia: sa1111: provide device clock
From: Dmitry Eremin-Solenikov @ 2014-11-06 7:41 UTC (permalink / raw)
To: linux-fbdev
Both pxa2xx (long ago) and sa1100 (now) make use of clock device to get
the cpu speed. Make sa1111 glue code provide clock to platform layer.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/pcmcia/sa1111_generic.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/pcmcia/sa1111_generic.c b/drivers/pcmcia/sa1111_generic.c
index 65b02c3..c5988be 100644
--- a/drivers/pcmcia/sa1111_generic.c
+++ b/drivers/pcmcia/sa1111_generic.c
@@ -145,6 +145,9 @@ int sa1111_pcmcia_add(struct sa1111_dev *dev, struct pcmcia_low_level *ops,
return -ENOMEM;
s->soc.nr = ops->first + i;
+ s->soc.clk = clk_get(&dev->dev, NULL);
+ if (IS_ERR(s->soc.clk))
+ return -ENODEV;
soc_pcmcia_init_one(&s->soc, ops, &dev->dev);
s->dev = dev;
if (s->soc.nr) {
@@ -220,6 +223,7 @@ static int pcmcia_remove(struct sa1111_dev *dev)
for (; s; s = next) {
next = s->next;
soc_pcmcia_remove_one(&s->soc);
+ clk_put(s->soc.clk);
kfree(s);
}
--
2.1.1
^ permalink raw reply related
* Re: [PATCH] fbdev: mxsfb: Add support for mx6sl and mx6sx
From: Fabio Estevam @ 2014-11-06 13:00 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1414243727-23447-1-git-send-email-festevam@gmail.com>
Hi Tomi,
On Sat, Oct 25, 2014 at 11:28 AM, Fabio Estevam <festevam@gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> mx6sl and mx6sx share the same LCD controller as mx23 and mx28.
>
> Add support for it.
>
> The basic difference is the number of clocks that are required:
>
> - mx23/mx28: only one clock
> - mx6sl: two clocks
> - mx6sx: three clocks
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> Changes since RFC:
> - Simplified the clock handling as suggested by Tomi
If you are happy with this one, could we get it into 3.19? Thanks
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox