* Re: Add Allwinner Q8 tablets hardware manager
From: Pierre-Hugues Husson @ 2016-10-27 17:31 UTC (permalink / raw)
To: Hans de Goede
Cc: Mark Rutland, devicetree, Arnd Bergmann, Greg Kroah-Hartman,
Pantelis Antoniou, Chen-Yu Tsai, Rob Herring, Maxime Ripard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <4cfdd415-1965-7be9-b204-86a9931683a6-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-10-27 16:53 GMT+02:00 Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>:
> Hi,
>
> No, the firmware-name (and matching resolution as different firmwares
> report different axis-ranges for the same digitizer) is selected
> primarily by the touchscreen_variant which sets: touchscreen_fw_name,
> touchscreen_width and touchscreen_height.
>
> The touchscreen_variant module option defaults to -1 which means "auto",
> when it is auto it gets set based on the touchscreen / accelerometer
> combination (which more or less uniquely identifies boards sofar),
> likewise all the other touchscreen module options default to -1,
> but can be overridden from the commandline.
>
> The intention is for things to just work, the commandline options are
> there as a fallback.
Ok, so I was really off. Sorry.
Now I think I understand the full complexity of the problem.
> We could just have:
>
> i2c-probe-stop-at-first-match-0 = <&touchscreen1>, <&touchscreen2>,
> <&touchscreen3>;
> i2c-probe-stop-at-first-match-1 = <&accelerometer1>,
> <&accelerometer2>;
>
> And have the i2c bus code look for an i2c-probe-stop-at-first-match-[i++]
> property
> until it is not found. Having a child-node with its own compatible for this
> feels wrong, as it uses a hierarchy where there really is none.
Ok, looks much better indeed.
I had one case where accelerometers could be on either i2c1 or i2c5.
Do you think this could be handled as well, or this makes things much
more complicated to fit in the i2c driver?
> So this would require us to be able to filter (to use your example)
> on if another i2c device is found and on which address it is found,
> that does not even take the rda559x check into account and is
> going to cause interesting ordering issues, how do we know when
> we can actually do the filtering if some of the variables we are
> filtering on are set by other auto-detected paths. Which auto-detect /
> i2c-probe-stop-at-first-match list do we execute first ? Worse
> actually for accelerometer orientation I will likely need to
> set the mount-matrix based on the detected touchscreen ...
>
> The rda559x here is a sdio wifi chip, which is also connected to the
> i2c, and currently is detected through i2c to be able to separately
> identify 2 q8 boards which share the same touchscreen + accelerometer
> combination and who knows what other checks I or other people can
> come up with to differentiate board variants which do not have
> a simple eeprom to uniquely id them.
>
> So as said before, no this cannot be all done in dt without
> adding a turing complete language to dt, and that is just to
> select which touchscreen_variant to use.
Ok, now that I understand the scope of your needs.
I agree with you, this needs a (close to) turing complete language.
I'm still not really happy about doing it in a driver, but I agree the
full scope you need is scarce enough.
Assuming this is done in a driver, there would need to be some
plumbing between i2c-probe-stop-at-first-match, device's probe
function and your driver, so that your driver only does the various
if/cases and DT changes, but there is no actual device communication
done in that driver.
> Then there also the probem of the combinatorial explosion having
> not only 2 firmware files but also invert-x and invert-y flags causes:
> We have 2 revisions with each 2 different firmware-files (more actually
> but I've reduced the set since some firmwares are compatible) with each
> both the x- and / or y axis as normal or inverted, for a total of:
> 2 (revision) * 2 (firmware-files) * 2 (x-inverted or not) * 2 (y...) = 16
> touchscreen variants, which means dt nodes for touchscreen1 to touchscreen16
> and that is just the silead gsl1680, some of these tablets also have
> elan or zeitec touchscreen controllers.
>
> Now imagine what happens if a new board comes out which needs a 3th firmware
> file... I hope you can understand this is not a route I want to go.
Right, I agree with you.
> Another problem is that if a user encounters the need for a new firmware
> variant he can now not easily try this (where as before we had
> module options to separately override firmware-name, the size, etc.
>
> As written in my previous mail, this is all rather gsl1680 specific,
> and esp. being able to override the firmware-name, the size, etc.
> through module options is going to be useful (to ask endusers to test
> stuff without recompiling) on x86 too. So we will likely want to add
> most of the necessary stuff to the silead driver anyways.
That's not currently the case, but can't we assume it will become easy
for users to install a DT overlay?
This would drop all your needs of module parameters, and would
actually be more modulable than your current scheme.
It is a more longer term thought, and could instead apply to further
boards having the same sort of troubles as you, rather than for this
first driver.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V3 2/2] iio: adc: spmi-vadc: Changes to support different scaling
From: Phani A, Rama Krishna @ 2016-10-27 17:37 UTC (permalink / raw)
To: Stanimir Varbanov, linux-iio-u79uwXL29TY76Z2rM5mHXA,
jic23-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
smohanad-sgV2jX0FEOL9JmXXK+q4OQ, mgautam-sgV2jX0FEOL9JmXXK+q4OQ,
sivaa-sgV2jX0FEOL9JmXXK+q4OQ, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
Julia.Lawall-L2FTfq7BK8M
In-Reply-To: <8418e7f1-55d9-2dfa-1dc7-5960f9da0305-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi Stan,
On 27-Oct-16 4:48 PM, Stanimir Varbanov wrote:
> Hi Rama,
>
> On 10/26/2016 05:41 PM, Rama Krishna Phani A wrote:
>> Polling can also be used for End of conversion completion. Implement logic
>> to choose either polling or interrupt for End of conversion completion.
>> Scaling can be done on the voltage to report adc code in physical units.
>> Add changes to support different scale functions to convert adc code to
>> physical units.
>>
>> Signed-off-by: Rama Krishna Phani A <rphani-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> ---
>> .../devicetree/bindings/iio/adc/qcom,spmi-vadc.txt | 14 ++
>> drivers/iio/adc/qcom-spmi-vadc.c | 263 +++++++++++++++++----
>> 2 files changed, 236 insertions(+), 41 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
>> index 0fb4613..39e31c0e 100644
>> --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
>> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
>> @@ -37,6 +37,12 @@ VADC node:
>> Value type: <prop-encoded-array>
>> Definition: End of conversion interrupt.
>>
>> +- qcom,vadc-poll-eoc:
>> + Usage: optional
>> + Value type: <bool>
>> + Definition: Use polling instead of interrupts for End of Conversion
>> + completion.
>
> Why you need to add such a flag in DT?
>
> The DT should describe hardware details not how the driver will choose
> pooling vs interrupt.
>
> On which use-case you would prefer pooling?
>
Few PMIC's support interrupt functionality for ADC where as few PMIC's
dont support. Based on the functionality that is supported in hardware
we choose whether to go for polling or for interrupt.
>> +
>> Channel node properties:
>>
>> - reg:
>> @@ -92,6 +98,14 @@ Channel node properties:
>> Valid values are: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512
>> If property is not found, 1 sample will be used.
>>
>> +- qcom,scale-function:
>> + Usage: optional
>> + Value type: <u32>
>> + Definition: Scaling function used to convert raw ADC code to
>> + units specific to a given channel. Scaled units can be
>> + microvolts, millidegC.Valid values are: 0, 1, 2, 3, 4.
>> + If property is not found, 0 scaling will be used.
>
> This shouldn't be in DT binding. Just select the scale function for each
> channel in the driver based on compatible property.
>
>
Ok ., Will remove this binding from DT, implement logic in driver and
will post next patch.
Thanks,
Ramakrishna
^ permalink raw reply
* Re: [PATCH 2/4] Input: goodix - Allow tweaking of configuration file dynamically
From: Bastien Nocera @ 2016-10-27 17:41 UTC (permalink / raw)
To: Franklin S Cooper Jr, dmitry.torokhov, robh+dt, octavian.purdila,
irina.tirdea, merker, linux-input, devicetree, linux-kernel,
nsekhar, nm
In-Reply-To: <f3a9de30-eba6-0738-ed91-f4834f142a2c@ti.com>
On Thu, 2016-10-27 at 11:58 -0500, Franklin S Cooper Jr wrote:
>
> On 10/27/2016 05:33 AM, Bastien Nocera wrote:
> > On Thu, 2016-10-20 at 14:59 -0500, Franklin S Cooper Jr wrote:
> > > Some goodix touchscreen controllers don't have the correct
> > > configuration
> > > firmware for the display panel it is attached to. Therefore,
> > > settings
> > > such
> > > as touchscreen x and y size may need to be passed in via DT and
> > > have
> > > the
> > > panel reprogrammed for the updated touchscreen resolution.
> > >
> > > This patchset adds support for reading the current configuration
> > > firmware
> > > on the panel and allowing it to be modified and rewritten back to
> > > the
> > > device.
> > >
> > > Currently this function is unused but later patches will make use
> > > of
> > > it.
> > >
> > > Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> > > ---
> > > drivers/input/touchscreen/goodix.c | 28
> > > ++++++++++++++++++++++++++++
> > > 1 file changed, 28 insertions(+)
> > >
> > > diff --git a/drivers/input/touchscreen/goodix.c
> > > b/drivers/input/touchscreen/goodix.c
> > > index a43c8ca..01e12f8 100644
> > > --- a/drivers/input/touchscreen/goodix.c
> > > +++ b/drivers/input/touchscreen/goodix.c
> > > @@ -478,6 +478,34 @@ static int goodix_get_gpio_config(struct
> > > goodix_ts_data *ts)
> > > return 0;
> > > }
> > >
> > > +static void goodix_tweak_config(struct goodix_ts_data *ts)
> > > +{
> > > + u8 config[GOODIX_CONFIG_MAX_LENGTH];
> > > + int error;
> > > + int raw_cfg_len;
> > > + u8 check_sum = 0;
> > > +
> > > + raw_cfg_len = ts->cfg_len - 2;
> > > +
> > > + error = goodix_i2c_read(ts->client,
> > > GOODIX_REG_CONFIG_DATA,
> > > + config, ts->cfg_len);
> > > + if (error) {
> > > + dev_warn(&ts->client->dev,
> > > + "Error reading config (%d), avoid
> > > tweaking
> > > config\n",
> > > + error);
> > > + return;
> > > + }
> >
> > Please add a placeholder comment here, to go along with the commit
> > message explanation.
>
> You just want a comment here stating that changes to the firmware
> should
> be made here?
Yes, at least for this intermediary patch. You can remove in in
subsequent patches when it's clearer that this is where things go.
> > > + check_sum = goodix_calculate_checksum(ts->cfg_len,
> > > config);
> > > +
> > > + config[raw_cfg_len] = check_sum;
> > > + config[raw_cfg_len + 1] = 1;
> > > +
> > > + error = goodix_send_cfg(ts, ts->cfg_len, config);
> > > + if (error)
> > > + dev_warn(&ts->client->dev,
> > > + "Error writing config (%d)\n", error);
> > > +}
> > > /**
> > > * goodix_read_config - Read the embedded configuration of the
> > > panel
> > > *
^ permalink raw reply
* Re: [PATCH 4/4] Input: goodix - Support interchanging x and y coordinates in hardware
From: Franklin S Cooper Jr @ 2016-10-27 17:42 UTC (permalink / raw)
To: Bastien Nocera, Rob Herring
Cc: dmitry.torokhov, octavian.purdila, irina.tirdea, merker,
linux-input, devicetree, linux-kernel, nsekhar, nm
In-Reply-To: <1477564471.2458.11.camel@hadess.net>
On 10/27/2016 05:34 AM, Bastien Nocera wrote:
> On Wed, 2016-10-26 at 18:18 -0500, Rob Herring wrote:
>> On Thu, Oct 20, 2016 at 02:59:17PM -0500, Franklin S Cooper Jr wrote:
>>>
> <snip>
>> I'm not sure I follow why existing properties don't cover this.
>
> Me neither. I certainly don't understand why the driver can't mangle
> the data from the touchscreen all it wants. It's not like user-space is
> talking to the touchscreen directly.
>
Sorry the above could of been clearer.
Lets ignore talking about X and Y axis for a little bit since that
really depends on the default touchscreen config values and the way it
is mounted on the touchscreen. Now lets say when your interacting with
the touchscreen the touchscreen controller outputs a max value of 1280
when moving your finger horizontally and 800 when moving your finger
vertically.
<-1280->
------
| | ^
| | |
| | 800
| | |
------ V
So no matter what your horizontal range is 0-1280 and your vertical
range is 0-800. Now based on the above diagram you can see that usually
you want the longer side to have a higher resolution. So you may want a
vertical range of 0-1280 and a horizontal range from 0-800 instead.
So lets add labels to the original diagram and assume that the x and y
axis from the driver/user-space perspective is as follows.
<-1280-> (X)
------
| | ^
| | |
| | 800 (Y)
| | |
------ V
The only thing the driver (software) has the ability to do is change the
"orientation".
<-1280-> (Y)
------
| | ^
| | |
| | 800 (X)
| | |
------ V
However, this doesn't change the resolution ie range of values in the
horizontal and vertical direction the touch screen controller will
report. Only the hardware can determine the resolution it will use. The
interchange bit I set essentially swaps the range that the controller is
currently programmed to use which in my first diagram the horizontal
range was 0-1280 and my vertical range is 0-800. So by setting this
interchange bit in hardware the horizontal range will now be 0-800 while
the vertical range will be 0-1280 which is what we want.
Does this clarify things? I messed up the second diagram in my commit
message which is probably what caused the confusion.
^ permalink raw reply
* Re: [PATCH V4 0/5] firmware: Add support for TI System Control Interface (TI-SCI) protocol driver
From: Tero Kristo @ 2016-10-27 17:46 UTC (permalink / raw)
To: Kevin Hilman
Cc: Nishanth Menon, Santosh Shilimkar, Dave Gerlach, Lokesh Vutla,
Andrew Davis, Russell King, Russ Dill, Sudeep Holla,
linux-arm-kernel, devicetree, linux-pm, linux-kernel, Rob Herring
In-Reply-To: <m260odhjcb.fsf@baylibre.com>
On 27/10/16 19:01, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
>
>> On 19/10/16 02:08, Nishanth Menon wrote:
>>> Version 4 of the series is basically a rebase to v4.9-rc1, no functional
>>> changes.
>>
>> Any final comments on this series, or shall I send a pull-req forward?
>> Very minimal changes compared to v3 so should be good to go imo.
>
> Not a comment on the series, but a question on TI-SCI.
>
> Will the uC firmware be open like it was on AM335x?
Currently it seems like it will be closed. :(
-Tero
^ permalink raw reply
* Re: [PATCH V4 0/5] firmware: Add support for TI System Control Interface (TI-SCI) protocol driver
From: Tero Kristo @ 2016-10-27 17:47 UTC (permalink / raw)
To: Santosh Shilimkar, Nishanth Menon, Santosh Shilimkar
Cc: Dave Gerlach, Lokesh Vutla, Andrew Davis, Russell King, Russ Dill,
Sudeep Holla, linux-arm-kernel, devicetree, linux-pm,
linux-kernel, Rob Herring, Kevin Hilman
In-Reply-To: <45f55012-f027-51d1-bdf1-6fa1950f59ed@oracle.com>
On 26/10/16 22:56, Santosh Shilimkar wrote:
> On 10/25/2016 10:34 AM, Tero Kristo wrote:
>> On 19/10/16 02:08, Nishanth Menon wrote:
>>> Version 4 of the series is basically a rebase to v4.9-rc1, no functional
>>> changes.
>>
>> Hi,
>>
>> Any final comments on this series, or shall I send a pull-req forward?
>> Very minimal changes compared to v3 so should be good to go imo.
>>
> The patchset looks fine to me from brief scan so please Go from
> my side at least for the pull request.
Queued for 4.10, pull request sent also. Thanks.
-Tero
^ permalink raw reply
* [PATCH 1/2] ARM: dts: exynos: Use macro for PWM signal polarity in Exynos4 boards
From: Javier Martinez Canillas @ 2016-10-27 17:47 UTC (permalink / raw)
To: linux-kernel
Cc: Javier Martinez Canillas, devicetree, Kukjin Kim, Russell King,
linux-samsung-soc, Rob Herring, Mark Rutland, Krzysztof Kozlowski,
linux-arm-kernel
Using the PWM_POLARITY_INVERTED macro instead of the hardcoded number
0 makes the DTS easier to read.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 3 ++-
arch/arm/boot/dts/exynos4412-trats2.dts | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 99634c54dca9..480a80624b77 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -12,6 +12,7 @@
*/
/dts-v1/;
+#include <dt-bindings/pwm/pwm.h>
#include "exynos4412-odroid-common.dtsi"
/ {
@@ -35,7 +36,7 @@
fan0: pwm-fan {
compatible = "pwm-fan";
- pwms = <&pwm 0 10000 0>;
+ pwms = <&pwm 0 10000 PWM_POLARITY_INVERTED>;
cooling-min-state = <0>;
cooling-max-state = <3>;
#cooling-cells = <2>;
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
index 41ecd6d465a7..63ad30507d4f 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -18,6 +18,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/clock/maxim,max77686.h>
+#include <dt-bindings/pwm/pwm.h>
/ {
model = "Samsung Trats 2 based on Exynos4412";
@@ -164,7 +165,7 @@
max77693_haptic {
compatible = "maxim,max77693-haptic";
haptic-supply = <&ldo26_reg>;
- pwms = <&pwm 0 38022 0>;
+ pwms = <&pwm 0 38022 PWM_POLARITY_INVERTED>;
};
charger {
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: exynos: Use macro for PWM signal polarity in Exynos5 boards
From: Javier Martinez Canillas @ 2016-10-27 17:47 UTC (permalink / raw)
To: linux-kernel
Cc: Javier Martinez Canillas, devicetree, Kukjin Kim, Russell King,
linux-samsung-soc, Rob Herring, Mark Rutland, Krzysztof Kozlowski,
linux-arm-kernel
In-Reply-To: <1477590438-18095-1-git-send-email-javier@osg.samsung.com>
Using the PWM_POLARITY_INVERTED macro instead of the hardcoded number
0 makes the DTS easier to read.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 ++-
arch/arm/boot/dts/exynos5410-odroidxu.dts | 2 +-
arch/arm/boot/dts/exynos5420-peach-pit.dts | 3 ++-
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 3 ++-
arch/arm/boot/dts/exynos5422-odroidxu4.dts | 2 +-
arch/arm/boot/dts/exynos54xx-odroidxu-leds.dtsi | 5 +++--
arch/arm/boot/dts/exynos5800-peach-pi.dts | 3 ++-
7 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 8f3a80430748..4df36f7263fd 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -12,6 +12,7 @@
#include <dt-bindings/clock/maxim,max77686.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/input/input.h>
+#include <dt-bindings/pwm/pwm.h>
#include "exynos5250.dtsi"
/ {
@@ -198,7 +199,7 @@
backlight: backlight {
compatible = "pwm-backlight";
- pwms = <&pwm 0 1000000 0>;
+ pwms = <&pwm 0 1000000 PWM_POLARITY_INVERTED>;
brightness-levels = <0 100 500 1000 1500 2000 2500 2800>;
default-brightness-level = <7>;
enable-gpios = <&gpx3 0 GPIO_ACTIVE_HIGH>;
diff --git a/arch/arm/boot/dts/exynos5410-odroidxu.dts b/arch/arm/boot/dts/exynos5410-odroidxu.dts
index c4de1353e5df..56adaac1f4ec 100644
--- a/arch/arm/boot/dts/exynos5410-odroidxu.dts
+++ b/arch/arm/boot/dts/exynos5410-odroidxu.dts
@@ -40,7 +40,7 @@
fan0: pwm-fan {
compatible = "pwm-fan";
- pwms = <&pwm 0 20972 0>;
+ pwms = <&pwm 0 20972 PWM_POLARITY_INVERTED>;
cooling-min-state = <0>;
cooling-max-state = <3>;
#cooling-cells = <2>;
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 1f964ec35c5e..d83a12bb7112 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -13,6 +13,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/clock/maxim,max77802.h>
+#include <dt-bindings/pwm/pwm.h>
#include <dt-bindings/regulator/maxim,max77802.h>
#include "exynos5420.dtsi"
#include "exynos5420-cpus.dtsi"
@@ -37,7 +38,7 @@
backlight: backlight {
compatible = "pwm-backlight";
- pwms = <&pwm 0 1000000 0>;
+ pwms = <&pwm 0 1000000 PWM_POLARITY_INVERTED>;
brightness-levels = <0 100 500 1000 1500 2000 2500 2800>;
default-brightness-level = <7>;
power-supply = <&tps65090_fet1>;
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 246d298557f5..791af504a79f 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -15,6 +15,7 @@
#include <dt-bindings/clock/samsung,s2mps11.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pwm/pwm.h>
#include <dt-bindings/sound/samsung-i2s.h>
#include "exynos5800.dtsi"
#include "exynos5422-cpus.dtsi"
@@ -51,7 +52,7 @@
fan0: pwm-fan {
compatible = "pwm-fan";
- pwms = <&pwm 0 20972 0>;
+ pwms = <&pwm 0 20972 PWM_POLARITY_INVERTED>;
cooling-min-state = <0>;
cooling-max-state = <3>;
#cooling-cells = <2>;
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
index 2faf88627a48..93ac1d201f16 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
@@ -24,7 +24,7 @@
blueled {
label = "blue:heartbeat";
- pwms = <&pwm 2 2000000 0>;
+ pwms = <&pwm 2 2000000 PWM_POLARITY_INVERTED>;
pwm-names = "pwm2";
max_brightness = <255>;
linux,default-trigger = "heartbeat";
diff --git a/arch/arm/boot/dts/exynos54xx-odroidxu-leds.dtsi b/arch/arm/boot/dts/exynos54xx-odroidxu-leds.dtsi
index 0ed30206625c..1e3d65d34167 100644
--- a/arch/arm/boot/dts/exynos54xx-odroidxu-leds.dtsi
+++ b/arch/arm/boot/dts/exynos54xx-odroidxu-leds.dtsi
@@ -12,6 +12,7 @@
*/
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pwm/pwm.h>
/ {
pwmleds {
@@ -19,7 +20,7 @@
greenled {
label = "green:mmc0";
- pwms = <&pwm 1 2000000 0>;
+ pwms = <&pwm 1 2000000 PWM_POLARITY_INVERTED>;
pwm-names = "pwm1";
/*
* Green LED is much brighter than the others
@@ -31,7 +32,7 @@
blueled {
label = "blue:heartbeat";
- pwms = <&pwm 2 2000000 0>;
+ pwms = <&pwm 2 2000000 PWM_POLARITY_INVERTED>;
pwm-names = "pwm2";
max_brightness = <255>;
linux,default-trigger = "heartbeat";
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index f9ff7f07ae0c..b1bf73f51e9c 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -13,6 +13,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/clock/maxim,max77802.h>
+#include <dt-bindings/pwm/pwm.h>
#include <dt-bindings/regulator/maxim,max77802.h>
#include "exynos5800.dtsi"
#include "exynos5420-cpus.dtsi"
@@ -35,7 +36,7 @@
backlight: backlight {
compatible = "pwm-backlight";
- pwms = <&pwm 0 1000000 0>;
+ pwms = <&pwm 0 1000000 PWM_POLARITY_INVERTED>;
brightness-levels = <0 100 500 1000 1500 2000 2500 2800>;
default-brightness-level = <7>;
enable-gpios = <&gpx2 2 GPIO_ACTIVE_HIGH>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 01/14] dma: sun6i-dma: Add burst case of 4
From: Maxime Ripard @ 2016-10-27 17:51 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: Mylène Josserand, vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
wens-jdAy2FN1RRM, mturquette-rdvid1DuHRBWk0Htik3J/w,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
broonie-DgEjT+Ai2ygdnm+yROfE0A, perex-/Fr2/VpizcU,
tiwai-IBi9RG/b67k, lee.jones-QSEj5FYQhm4dnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161023183107.5b75b6aad62853378713299f-GANU6spQydw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 5093 bytes --]
On Sun, Oct 23, 2016 at 06:31:07PM +0200, Jean-Francois Moine wrote:
> On Tue, 4 Oct 2016 18:55:54 +0200
> Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
> > On Tue, Oct 04, 2016 at 12:40:11PM +0200, Jean-Francois Moine wrote:
> > > On Tue, 4 Oct 2016 11:46:14 +0200
> > > Mylène Josserand <mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > >
> > > > Add the case of a burst of 4 which is handled by the SoC.
> > > >
> > > > Signed-off-by: Mylène Josserand <mylene.josserand@free-electrons.com>
> > > > ---
> > > > drivers/dma/sun6i-dma.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> > > > index 8346199..0485204 100644
> > > > --- a/drivers/dma/sun6i-dma.c
> > > > +++ b/drivers/dma/sun6i-dma.c
> > > > @@ -240,6 +240,8 @@ static inline s8 convert_burst(u32 maxburst)
> > > > switch (maxburst) {
> > > > case 1:
> > > > return 0;
> > > > + case 4:
> > > > + return 1;
> > > > case 8:
> > > > return 2;
> > > > default:
> > > > --
> > > > 2.9.3
> > >
> > > This patch has already been rejected by Maxime in the threads
> > > http://www.spinics.net/lists/dmaengine/msg08610.html
> > > and
> > > http://www.spinics.net/lists/dmaengine/msg08719.html
> > >
> > > I hope you will find the way he wants for this maxburst to be added.
> >
> > I was talking about something along these lines (not tested):
>
> I wonder why you don't submit this yourself.
I thought you were the one who cared. You asked for what I had in
mind, here it is.
> > -------8<---------
> > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> > index 83461994e418..573ac4608293 100644
> > --- a/drivers/dma/sun6i-dma.c
> > +++ b/drivers/dma/sun6i-dma.c
> > @@ -240,6 +240,8 @@ static inline s8 convert_burst(u32 maxburst)
> > switch (maxburst) {
> > case 1:
> > return 0;
> > + case 4:
> > + return 1;
> > case 8:
> > return 2;
> > default:
> > @@ -1110,11 +1112,19 @@ static int sun6i_dma_probe(struct platform_device *pdev)
> > sdc->slave.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> > BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> > BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
> > + sdc->slave.dst_bursts = BIT(1) | BIT(8);
> > + sdc->slave.src_bursts = BIT(1) | BIT(8);
> > sdc->slave.directions = BIT(DMA_DEV_TO_MEM) |
> > BIT(DMA_MEM_TO_DEV);
> > sdc->slave.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
> > sdc->slave.dev = &pdev->dev;
> >
> > + if (of_device_is_compatible(pdev->dev.of_node,
> > + "allwinner,sun8i-h3-dma")) {
> > + sdc->slave.dst_bursts |= BIT(4);
> > + sdc->slave.src_bursts |= BIT(4);
> > + }
> > +
> > sdc->pchans = devm_kcalloc(&pdev->dev, sdc->cfg->nr_max_channels,
> > sizeof(struct sun6i_pchan), GFP_KERNEL);
> > if (!sdc->pchans)
> > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > index cc535a478bae..f7bbec24bb58 100644
> > --- a/include/linux/dmaengine.h
> > +++ b/include/linux/dmaengine.h
> > @@ -673,6 +673,8 @@ struct dma_filter {
> > * each type of direction, the dma controller should fill (1 <<
> > * <TYPE>) and same should be checked by controller as well
> > * @max_burst: max burst capability per-transfer
> > + * @dst_bursts: bitfield of the available burst sizes for the destination
> > + * @src_bursts: bitfield of the available burst sizes for the source
>
> You did not define dst_bursts nor src_bursts.
>
> > * @residue_granularity: granularity of the transfer residue reported
> > * by tx_status
> > * @device_alloc_chan_resources: allocate resources and return the
> > @@ -800,6 +802,14 @@ struct dma_device {
> > static inline int dmaengine_slave_config(struct dma_chan *chan,
> > struct dma_slave_config *config)
> > {
> > + if (config->src_maxburst && config->device->src_bursts &&
> > + !(BIT(config->src_maxburst) & config->device->src_bursts))
>
> The maxburst may be as big as 4Kibytes, then, I am not sure that this
> code will work!
>
> > + return -EINVAL;
> > +
> > + if (config->dst_maxburst && config->device->dst_bursts &&
> > + !(BIT(config->dst_maxburst) & config->device->dst_bursts))
> > + return -EINVAL;
> > +
> > if (chan->device->device_config)
> > return chan->device->device_config(chan, config);
> > -------8<------------
>
> Yes, I know that the burst size is always a power of 2.
> The best way to check it would be to change the {src,dts}_maxburst to a
> bitmap of the possible bursts as 0x0d for 1,4 and 8 bytes. But this
> asks for a lot of changes...
To be honest, I'm not really a big fan of those tree wide changes
without any way to maintain compatibility. It ends up in a single,
huge patch if we want to maintain bisectability that just isn't
reviewable.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] Input: goodix - Support interchanging x and y coordinates in hardware
From: Franklin S Cooper Jr @ 2016-10-27 17:54 UTC (permalink / raw)
To: Rob Herring
Cc: dmitry.torokhov, hadess, octavian.purdila, irina.tirdea, merker,
linux-input, devicetree, linux-kernel, nsekhar, nm
In-Reply-To: <20161026231816.a35orxe3mpsvcx3m@rob-hp-laptop>
On 10/26/2016 06:18 PM, Rob Herring wrote:
> On Thu, Oct 20, 2016 at 02:59:17PM -0500, Franklin S Cooper Jr wrote:
>> On systems with a fixed display/touchscreen orientation it is important to
>> pass in the "correct" x and y coordinates based on the orientation.
>> Currently, to support landscape and portrait touchscreen-swapped-x-y
>> simply does the following:
>>
>> Assuming touchscreen is as follows:
>> X: 1280 Y:800 programmed in touchscreen controller and also interchange
>> bit cleared. Assuming ts mounted in portrait mode.
>>
>> 1280 (X)
>> ------
>> | |
>> | | 800 (Y)
>> | |
>> | |
>> ------
>>
>> 800 (Y)
>> ------
>> | |
>> | | 1280 (X)
>> | |
>> | |
>> ------
>>
>> However, the above isn't really what we want especially in distros that
>> assumes a fixed orientation. In this case what we really want is to
>> interchange the x and y coordinates so the Y coordinate can return a max
>> value of 1280 and X can return a max value of 800.
>>
>> 800 (X)
>> ------
>> | |
>> | | 1280 (Y)
>> | |
>> | |
>> ------
>>
>> Since the driver is limited to the value reported by the touchscreen
>> controller this issue can't be fixed purely in the driver. Therefore,
>> add a new DT property that supports interchanging X and Y coordinates
>> internally within the hardware.
>
> I'm not sure I follow why existing properties don't cover this.
>
>>
>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>> ---
>> .../devicetree/bindings/input/touchscreen/goodix.txt | 2 ++
>> drivers/input/touchscreen/goodix.c | 13 +++++++++++++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
>> index ebc7cb7..b8be2ab 100644
>> --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
>> +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
>> @@ -25,6 +25,8 @@ Optional properties:
>> - touchscreen-inverted-y : Y axis is inverted (boolean)
>> - touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
>> (swapping is done after inverting the axis)
>> + - touchscreen-inter-x-y : X and Y maximum values programmed in the device
>> + are interchanged internally in hardware. (boolean)
>
> Minimally this should be vendor specific and have a vendor prefix I
> think.
Would "goodix,inter-x-y" work?
>
> Rob
>
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: bcm283x: fix typo in mailbox address
From: Eric Anholt @ 2016-10-27 18:00 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Stephen Warren
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Stefan Wahren
In-Reply-To: <1477505640-26658-2-git-send-email-stefan.wahren-eS4NqCHxEME@public.gmane.org>
Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org> writes:
> The address of the mailbox node in the bcm283x.dts has also a typo.
> So fix it accordingly.
>
> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> Fixes: 05b682b7a3b2 ("ARM: bcm2835: dt: Add the mailbox to the device tree")
I've marked these to be applied once Rob acks the docs change.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH 06/13] of: Remove prefix "__of_" and prefix "__" from local function names
From: Frank Rowand @ 2016-10-27 18:25 UTC (permalink / raw)
To: Rob Herring
Cc: Pantelis Antoniou, Pantelis Antoniou, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAL_JsqJdBAeAUfODEzvpNELmLj9ib1CKwQVsEVGsFYAnBuj_Kw@mail.gmail.com>
On 10/27/16 09:58, Rob Herring wrote:
> On Thu, Oct 27, 2016 at 11:35 AM, Frank Rowand <frowand.list@gmail.com> wrote:
>> On 10/27/16 05:47, Rob Herring wrote:
>>> On Tue, Oct 25, 2016 at 3:58 PM, <frowand.list@gmail.com> wrote:
>>>> From: Frank Rowand <frank.rowand@am.sony.com>
>>>
>>> I prefer to leave the prefixes and this is getting into pointless churn.
>>>
>>>>
>>>> Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
>>>> ---
>>>> drivers/of/resolver.c | 10 +++++-----
>>>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>>
>>
>> If I was just submitting this as a single patch, I would agree.
>>
>> But since I am making so many other changes, I think it makes
>> sense to do this as part of this series. It is broken apart
>> as a separate patch to be easy to review and not pollute any
>> of the other patches in the series.
>>
>> The prefixes add no value for a local function, but they do
>> add noise when reading code.
>
> The value is when reading the calling function, you know the function
> is a DT related function. You don't know it's a static function
It is more than that. A common convention in drivers/of/ is that
function blah() acquires a lock, calls function __blah(), and
releases the lock. Any function other than blah() that wants
to call __blah() must also hold the proper lock. The functions
whose name this patch changes do not fit this pattern.
> without looking up the function name. That said, I wouldn't object to
> code originally written either way, I just don't see the value in
> changing it.
>
> Rob
>
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v5 2/7] ASoC: sunxi: Add a simple HDMI CODEC
From: Mark Brown @ 2016-10-27 18:36 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: Chen-Yu Tsai, Dave Airlie, Liam Girdwood, Maxime Ripard,
Rob Herring, Linux-ALSA, devicetree, dri-devel, linux-arm-kernel,
linux-sunxi
In-Reply-To: <20161027191634.f2fa6478cd07d84a60274339-GANU6spQydw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]
On Thu, Oct 27, 2016 at 07:16:34PM +0200, Jean-Francois Moine wrote:
> Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> > There's already a driver for basically the same thing:
> > sound/soc/codec/hdmi-codec.c
> > You use it by registering a sub-device from your hdmi driver, with the
> > proper platform_data and callbacks. Grep for HDMI_CODEC_DRV_NAME for
> > platforms already using it.
> I know that for a long time, and I will not use it on any account: it is
> a gasworks!
If there are problems with what's there then articulate them and fix
them, don't just open code something separate. Just open coding
something else without any articulated reasoning is not helping things.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH V3 5/6] ARM: tegra: Add Tegra20 GMI support
From: Mirza Krak @ 2016-10-27 18:55 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all-JC7UmRfGjtg, Stephen Warren, Thierry Reding,
Jon Hunter, Alexandre Courbot, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
pdeschrijver-DDmLM1+adcrQT0dZR+AlfA, Prashant Gaikwad,
Michael Turquette, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, linux-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201610280016.MiLeMJw9%fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-10-27 19:09 GMT+02:00 kbuild test robot <lkp-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>:
> Hi Mirza,
>
> [auto build test ERROR on robh/for-next]
> [also build test ERROR on v4.9-rc2 next-20161027]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
> [Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
> [Check https://git-scm.com/docs/git-format-patch for more information]
>
> url: https://github.com/0day-ci/linux/commits/Mirza-Krak/clk-tegra-add-TEGRA20_CLK_NOR-to-init-table/20161027-225528
> base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
> config: arm-davinci_all_defconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm
>
> All errors (new ones prefixed by >>):
>
>>> Error: arch/arm/boot/dts/tegra20.dtsi:1.1-8 syntax error
> FATAL ERROR: Unable to parse input tree
That one was embarrassing. Sorry...
Best Regards
Mirza
^ permalink raw reply
* Re: Add Allwinner Q8 tablets hardware manager
From: Pierre-Hugues Husson @ 2016-10-27 19:04 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Hans de Goede, Mark Rutland, devicetree, Arnd Bergmann,
Greg Kroah-Hartman, Chen-Yu Tsai, Rob Herring, Maxime Ripard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <D75CB7DE-4165-4D2F-B40B-D2B6875C0172-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
2016-10-27 19:11 GMT+02:00 Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/HQFizaE/u3fw@public.gmane.orgm>:
>
> Hi Pierre,
>
> > On Oct 27, 2016, at 19:59 , Pierre-Hugues Husson <phh-8tEavu1zA38@public.gmane.org> wrote:
> >
> > 2016-10-27 17:52 GMT+02:00 Pantelis Antoniou <pantelis.antoniou@konsulko.com>:
> >> Yes there is no EEPROM but you might be able to map probing results to
> >> a fake ‘model’ number.
> >>
> >> Let me expand a bit:
> >>
> >> Assume that you have a number of probing steps, for example A, B, C each
> >> returning true or false, and C being executed only when B is ‘true’ you
> >> could do this to generate a bit field that identifies it.
> >>
> >> For example let’s assume that model FOO’s probing steps are
> >>
> >> A false, B true, C false -> 010
> >>
> >> Model’s BAR
> >>
> >> A true, B false, C don’t care -> 10x
> >>
> >> Mapping these to models could be
> >>
> >> Model FOO, (010 & 111) == 010 (all three probing steps must match)
> >>
> >> Model BAR, (10x & 110) = 100 (the first two probing steps must match)
> >
> > This method looks too complex on multiple grounds.
> > Assuming your method, I'm not too sure how this would actually be
> > described in a DTS.
> > Such probing steps should include reading/matching IDs in an EEPROM/on
> > an ADC, but it should also include the result of a driver's probe.
> > Also, drivers should have a way to report an ID/OTP instead of just a
> > boolean.
> >
>
> Err, I don’t think you got the point.
>
> The probing steps are done by a board specific probe driver.
> This driver performs the probing steps (which is exactly what Hans’s
> method now does) but instead of applying changes to the device tree
> programmatically generates a model string.
>
> This model string can be used by a general purpose overlay manager to apply
> the overlay(s) for the specific board. The plural part is important - read
> below.
Ok, I agree I didn't get the point, and I'm not sure I do now.
If I understand correctly, the difference between your method and
Hans', is that instead of manipulating directly OF properties based on
heuristics, there will be a heuristic to determine model revision, and
THEN apply overlays based on determined model revision.
If this is the correct interpretation, this means that for boards with
two possible accelerometers, a new driver is required, while something
as simple as i2c-probe-stop-at-first-match wouldn't require a new
driver.
> > As you mentioned, it is a way to distinguish models, not just a set of
> > parameters.
> > Does this mean that this DT would lead to loading various DT based on
> > the matching model, which would look like a FIT?
> > Also there is a modularity problem there. If I have phones with either
> > screen A or screen B, and with either accelerometer A or accelerometer
> > B, I would have to implement all four combinations.
> >
>
> The model lookup need not result in a simple overlay to apply.
>
> So for your case it would be:
>
> model corp,0 -> overlay screen A + overlay accel A
> model corp,1 -> overlay screen A + overlay accel B
> model corp,2 -> overlay screen B + overlay accel A
> model corp,3 -> overlay screen B + overlay accel B
>
> You don’t need the combinatorial number of overlays.
My worry initially was that all 4 "model corp" are needed, while with
using a simple approach like i2c-probe-stop-at-first-match, this
wouldn't be needed.
But now that I'm thinking of it again, for such a case to happen, this
would require to have OEMs picking random components for tablets of
one production batch. This wouldn't make any sense.
So I agree a model-based method should cover sufficient cases to be worthwhile.
I think it covers every device I've met.
Regards,
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] input: keyboard: Add devicetree support for lm8333
From: Gordan Markus @ 2016-10-27 19:17 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA; +Cc: Gordan Markuš
This adds LM8333 devicetree parsing for the keypad part.
Optional properties to specify the keypad driver active
time and debounce time.
Signed-off-by: Gordan Markuš <gordan.markus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
.../devicetree/bindings/input/ti,lm8333.txt | 45 ++++++++++++++++++
drivers/input/keyboard/lm8333.c | 54 ++++++++++++++++++++++
2 files changed, 99 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ti,lm8333.txt
diff --git a/Documentation/devicetree/bindings/input/ti,lm8333.txt b/Documentation/devicetree/bindings/input/ti,lm8333.txt
new file mode 100644
index 0000000..4100d48
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,lm8333.txt
@@ -0,0 +1,45 @@
+LM8333 Keypad
+
+Required properties:
+- compatible: Compatible property value should be "ti,lm8333".
+
+- reg: Physical base address of the peripheral and length of memory mapped
+ region.
+
+- interrupts: The interrupt number for the peripheral.
+
+- linux,keymap: The keymap to use
+ (see Documentation/devicetree/bindings/input/matrix-keymap.txt)
+
+Optional properties:
+- ti,active-time: Specify the time during which the keypad is scanned after
+ the last key is released, before entering Halt mode.
+ The active time must be longer than the debounce time.
+ Default 500 ms.
+
+- ti,debounce-time: Specify the keypad debounce time.
+ This can be used for reliable scanning of keyboards with noisy contacts.
+ Default 10 ms.
+
+Example:
+input {
+ compatible = "ti,lm8333";
+ reg = <0x51>;
+ interrupts = <5>;
+
+ ti,active-time = <750>;
+ ti,debounce-time = <20>;
+
+ linux,keymap = <
+ 0x0001001e
+ 0x00020030
+ 0x0003002e
+ 0x00040020
+ 0x00050012
+ 0x00060021
+ 0x00070022
+ 0x00080023
+ 0x01010017
+ 0x01020024
+ 0x01030025>;
+};
diff --git a/drivers/input/keyboard/lm8333.c b/drivers/input/keyboard/lm8333.c
index c717e8f..adb7d64 100644
--- a/drivers/input/keyboard/lm8333.c
+++ b/drivers/input/keyboard/lm8333.c
@@ -128,6 +128,51 @@ static irqreturn_t lm8333_irq_thread(int irq, void *data)
return IRQ_HANDLED;
}
+static struct lm8333_platform_data *lm8333_parse_dt(struct i2c_client *client)
+{
+ struct device_node *np = client->dev.of_node;
+ struct lm8333_platform_data *pdata;
+ struct matrix_keymap_data *matrix_data;
+ u32 *keymap;
+ u32 prop;
+ int len;
+
+ pdata = devm_kzalloc(&client->dev, sizeof(pdata),
+ GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ if (!of_property_read_u32(np, "ti,active-time", &prop))
+ pdata->active_time = prop;
+
+ if (!of_property_read_u32(np, "ti,debounce-time", &prop))
+ pdata->debounce_time = prop;
+ else
+ pdata->debounce_time = 10;
+
+ if (!of_get_property(np, "linux,keymap", &prop))
+ len = prop / sizeof(u32);
+ else {
+ dev_err(&client->dev, "no keymap data defined\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ keymap = devm_kzalloc(&client->dev, sizeof(len) * len, GFP_KERNEL);
+ matrix_data = devm_kzalloc(&client->dev, sizeof(matrix_data),
+ GFP_KERNEL);
+ if (!matrix_data || !keymap)
+ return ERR_PTR(-ENOMEM);
+
+ if (!of_property_read_u32_array(np, "linux,keymap", keymap, len)) {
+ matrix_data->keymap_size = len;
+ matrix_data->keymap = keymap;
+
+ pdata->matrix_data = matrix_data;
+ }
+
+ return pdata;
+}
+
static int lm8333_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -137,6 +182,15 @@ static int lm8333_probe(struct i2c_client *client,
struct input_dev *input;
int err, active_time;
+ if (!pdata && client->dev.of_node) {
+ pdata = lm8333_parse_dt(client);
+ if (IS_ERR(pdata)) {
+ dev_err(&client->dev,
+ "could not parse configuration\n");
+ return IS_ERR(pdata);
+ }
+ }
+
if (!pdata)
return -EINVAL;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: Add Allwinner Q8 tablets hardware manager
From: Pantelis Antoniou @ 2016-10-27 19:23 UTC (permalink / raw)
To: Pierre-Hugues Husson
Cc: Hans de Goede, Mark Rutland, devicetree, Arnd Bergmann,
Greg Kroah-Hartman, Chen-Yu Tsai, Rob Herring, Maxime Ripard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAJ-oXjS_=k4qE25t2b9eNnuqvVHf-1g7CZr81pPJx==aftF4xw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Pierre,
> On Oct 27, 2016, at 22:04 , Pierre-Hugues Husson <phh-8tEavu1zA38@public.gmane.org> wrote:
>
> 2016-10-27 19:11 GMT+02:00 Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>:
>>
>> Hi Pierre,
>>
>>> On Oct 27, 2016, at 19:59 , Pierre-Hugues Husson <phh-8tEavu1zA38@public.gmane.org> wrote:
>>>
>>> 2016-10-27 17:52 GMT+02:00 Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>:
>>>> Yes there is no EEPROM but you might be able to map probing results to
>>>> a fake ‘model’ number.
>>>>
>>>> Let me expand a bit:
>>>>
>>>> Assume that you have a number of probing steps, for example A, B, C each
>>>> returning true or false, and C being executed only when B is ‘true’ you
>>>> could do this to generate a bit field that identifies it.
>>>>
>>>> For example let’s assume that model FOO’s probing steps are
>>>>
>>>> A false, B true, C false -> 010
>>>>
>>>> Model’s BAR
>>>>
>>>> A true, B false, C don’t care -> 10x
>>>>
>>>> Mapping these to models could be
>>>>
>>>> Model FOO, (010 & 111) == 010 (all three probing steps must match)
>>>>
>>>> Model BAR, (10x & 110) = 100 (the first two probing steps must match)
>>>
>>> This method looks too complex on multiple grounds.
>>> Assuming your method, I'm not too sure how this would actually be
>>> described in a DTS.
>>> Such probing steps should include reading/matching IDs in an EEPROM/on
>>> an ADC, but it should also include the result of a driver's probe.
>>> Also, drivers should have a way to report an ID/OTP instead of just a
>>> boolean.
>>>
>>
>> Err, I don’t think you got the point.
>>
>> The probing steps are done by a board specific probe driver.
>> This driver performs the probing steps (which is exactly what Hans’s
>> method now does) but instead of applying changes to the device tree
>> programmatically generates a model string.
>>
>> This model string can be used by a general purpose overlay manager to apply
>> the overlay(s) for the specific board. The plural part is important - read
>> below.
>
> Ok, I agree I didn't get the point, and I'm not sure I do now.
> If I understand correctly, the difference between your method and
> Hans', is that instead of manipulating directly OF properties based on
> heuristics, there will be a heuristic to determine model revision, and
> THEN apply overlays based on determined model revision.
>
> If this is the correct interpretation, this means that for boards with
> two possible accelerometers, a new driver is required, while something
> as simple as i2c-probe-stop-at-first-match wouldn't require a new
> driver.
>
It does require a new driver, but the driver is simple a probing method
driver; it does not require to modify the actual drivers that are going
to be instantiated.
In DT terms for a board specific probe driver:
bpm: board_probe_method {
compatible = “foocorp,bar-board-probe”;
};
genm: generic_model_manager {
compatible = “generic-model-manager”;
probe-method = <&bpm>;
/* list of models and overlays to apply in sequence */
models {
foo-model-0 = “foo,bar,screen-A”, “foo,bar,accel-A”;
foo-model-1 = “foo,bar,screen-A”, “foo,bar,accel-B”;
foo-model-2 = “foo,bar,screen-B”, “foo,bar,accel-A”;
foo-model-3 = “foo,bar,screen-B”, “foo,bar,accel-B”;
};
};
The manager can call the single exported method which could be as simple
as:
const char *probe_identify();
In fact for things like i2c probe a generic probe method might suffice.
i2c_generic_bpm: generic_i2c_probe_method {
compatible = “i2c-generic-probe-method”;
models {
model@0 {
result = “foo-model-0”;
/* match when read at address 12 returns 5 */
/* and read at address 14 returns 0 */
/* format is command, bus, address, argument */
match = <MATCH_READ &i2c0 12 5>, <MATCH_READ &i2c0 0 14 0>;
… etc ...
};
};
};
>>> As you mentioned, it is a way to distinguish models, not just a set of
>>> parameters.
>>> Does this mean that this DT would lead to loading various DT based on
>>> the matching model, which would look like a FIT?
>>> Also there is a modularity problem there. If I have phones with either
>>> screen A or screen B, and with either accelerometer A or accelerometer
>>> B, I would have to implement all four combinations.
>>>
>>
>> The model lookup need not result in a simple overlay to apply.
>>
>> So for your case it would be:
>>
>> model corp,0 -> overlay screen A + overlay accel A
>> model corp,1 -> overlay screen A + overlay accel B
>> model corp,2 -> overlay screen B + overlay accel A
>> model corp,3 -> overlay screen B + overlay accel B
>>
>> You don’t need the combinatorial number of overlays.
>
> My worry initially was that all 4 "model corp" are needed, while with
> using a simple approach like i2c-probe-stop-at-first-match, this
> wouldn't be needed.
> But now that I'm thinking of it again, for such a case to happen, this
> would require to have OEMs picking random components for tablets of
> one production batch. This wouldn't make any sense.
> So I agree a model-based method should cover sufficient cases to be worthwhile.
> I think it covers every device I've met.
>
Yeah, model number in this case means both model and revision.
If components change you change the internal model number.
> Regards,
Regards
— Pantelis
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] Documentation: dt: reset: Add TI SCI reset binding
From: Andrew F. Davis @ 2016-10-27 19:24 UTC (permalink / raw)
To: Suman Anna, Nishanth Menon, Tero Kristo, Santosh Shilimkar,
Philipp Zabel, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel
In-Reply-To: <7a7907f6-e3bf-471b-cb56-1ff0d39802fb@ti.com>
On 10/27/2016 12:07 PM, Suman Anna wrote:
> Hi Andrew,
>
> On 10/26/2016 02:39 PM, Andrew F. Davis wrote:
>> Add TI SCI reset controller binding. This describes the DT binding
>> details for a reset controller node providing reset management services
>> to hardware blocks (reset consumers) using the Texas Instrument's System
>> Control Interface (TI SCI) protocol to communicate to a system controller
>> block present on the SoC.
>>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> [s-anna@ti.com: revise the binding format]
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>> .../devicetree/bindings/reset/ti,sci-reset.txt | 68 ++++++++++++++++++++++
>> MAINTAINERS | 1 +
>> 2 files changed, 69 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
>>
>> diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
>> new file mode 100644
>> index 0000000..189e284
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
>> @@ -0,0 +1,68 @@
>> +Texas Instruments System Control Interface (TI-SCI) Reset Controller
>> +=====================================================================
>> +
>> +Some TI SoCs contain a system controller (like the Power Management Micro
>> +Controller (PMMC) on Keystone K2G SoC) that are responsible for controlling
>> +the state of the various hardware modules present on the SoC. Communication
>> +between the host processor running an OS and the system controller happens
>> +through a protocol called TI System Control Interface (TI-SCI protocol).
>> +For TI SCI details, please refer to the document,
>> +Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>> +
>> +TI-SCI Reset Controller Node
>> +============================
>> +This reset controller node uses the TI SCI protocol to perform the reset
>> +management of various hardware modules present on the SoC.
>> +
>> +Required properties:
>> +--------------------
>> + - compatible : Should be "ti,sci-reset"
>> + - ti,sci : phandle to the TI SCI device to use for managing resets
>
> This does not look correct. Looks like you may have posted an older
> series. We should not be needing the ti,sci property anymore and this
> node should be a child node of the pmmc. Look at Tero's ti-sci clock series.
>
>> + - #reset-cells : Should be 2. Please see the reset consumer node below for
>> + usage details.
>> +
>> +TI-SCI Reset Consumer Nodes
>> +===========================
>> +Each of the reset consumer nodes should have the following properties,
>> +in addition to their own properties.
>> +
>> +Required properties:
>> +--------------------
>> + - resets : A phandle and reset specifier pair, one pair for each reset
>> + signal that affects the device, or that the device manages.
>> + The phandle should point to the TI-SCI reset controller node,
>> + and the reset specifier should have 2 cell-values. The first
>> + cell should contain the device ID, the values of which are
>> + specified in the <dt-bindings/genpd/<soc>.h> include file.
>> + The second cell should contain the reset mask value used by
>> + system controller, the values of which are specified in the
>> + include file <dt-bindings/reset/<soc>.h>, where <soc> is the
>> + name of the SoC involved, for example 'k2g'.
>> +
>> +Please also refer to Documentation/devicetree/bindings/reset/reset.txt for
>> +common reset controller usage by consumers.
>> +
>> +
>> +Example:
>> +--------
>> +The following example demonstrates both a TI-SCI reset controller node and a
>> +consumer (a DSP device) on the K2G SoC.
>> +
>> +#include <dt-bindings/genpd/k2g.h>
>> +#include <dt-bindings/reset/k2g.h>
>> +
>> +/ {
>> + soc {
>> + k2g_reset: k2g_reset {
>> + compatible = "ti,sci-reset";
>> + ti,sci = <&pmmc>;
>> + #reset-cells = <2>;
>> + };
>
> This example is also wrong. Please update it to represent this node as a
> child node of the pmmc.
>
Ah, yes, you are right, this change was handled transparently in code by
ti_sci_get_handle() so the documentation change was overlooked, will fix
for v2.
Thanks,
Andrew
> regards
> Suman
>
>> +
>> + dsp0: dsp0 {
>> + ...
>> + resets = <&k2g_reset K2G_DEV_CGEM0 K2G_DEV_CGEM0_DSP0_RESET>;
>> + ...
>> + };
>> + };
>> +};
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 6e93976..d8068df 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -11899,6 +11899,7 @@ F: drivers/soc/ti/ti_sci_pm_domains.c
>> F: Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>> F: include/dt-bindings/clock/k2g.h
>> F: drivers/clk/keystone/sci-clk.c
>> +F: Documentation/devicetree/bindings/reset/ti,sci-reset.txt
>>
>> THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
>> M: Hans Verkuil <hverkuil@xs4all.nl>
>>
>
^ permalink raw reply
* [PATCHv2 0/4] Add Altera A10SR Status & Control Monitor
From: tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx @ 2016-10-27 20:00 UTC (permalink / raw)
To: lee.jones-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, arnd-r2nGTMty4D4,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, geert-Td1EMuHUCqxL1ZNQvxDV9g,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Thor Thayer
From: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
This patch series adds the Altera Arria10 DevKit System Resource
chip's Status and Control Monitor to the A10SR Multi-Function
Device. An earlier patch added this to the hwmon class which
wasn't the proper place so this functionality is added to the
misc directory.
Version 2 changes the DT names from -mon to -monitor for better
readability and clarity and changed the previous version from
modular to built-in.
Thor Thayer (4):
dt-bindings: mfd: Add Altera Arria10 SR Monitor
misc: Add Altera Arria10 System Resource Control
mfd: altr-a10sr: Add Arria10 SR Monitor
ARM: socfpga: dts: Add Monitor to A10-SR MFD
.../devicetree/bindings/mfd/altera-a10sr.txt | 9 ++
MAINTAINERS | 1 +
arch/arm/boot/dts/socfpga_arria10_socdk.dtsi | 4 +
drivers/mfd/altera-a10sr.c | 4 +
drivers/misc/Kconfig | 7 +
drivers/misc/Makefile | 1 +
drivers/misc/altera-a10sr-monitor.c | 176 +++++++++++++++++++++
7 files changed, 202 insertions(+)
create mode 100644 drivers/misc/altera-a10sr-monitor.c
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCHv2 1/4] dt-bindings: mfd: Add Altera Arria10 SR Monitor
From: tthayer @ 2016-10-27 20:00 UTC (permalink / raw)
To: lee.jones, robh+dt, mark.rutland, dinguyen, linux, arnd, gregkh
Cc: davem, geert, devicetree, linux-kernel, linux-arm-kernel,
Thor Thayer
In-Reply-To: <1477598426-28125-1-git-send-email-tthayer@opensource.altera.com>
From: Thor Thayer <tthayer@opensource.altera.com>
Add the Arria10 DevKit System Resource Chip register and state
monitoring module to the MFD.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
---
Note: This needs to be applied to the bindings document that
was Acked & Applied but didn't reach the for-next branch.
See https://patchwork.ozlabs.org/patch/629397/
---
v2 Change compatible string -mon to -monitor for clarity
---
Documentation/devicetree/bindings/mfd/altera-a10sr.txt | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
index ea151f2..c47be28 100644
--- a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
+++ b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
@@ -18,6 +18,7 @@ The A10SR consists of these sub-devices:
Device Description
------ ----------
a10sr_gpio GPIO Controller
+a10sr_monitor Register and State Monitoring
Arria10 GPIO
Required Properties:
@@ -27,6 +28,10 @@ Required Properties:
the second cell is used to specify flags.
See ../gpio/gpio.txt for more information.
+Arria10 Register and State Monitor
+Required Properties:
+- compatible : Should be "altr,a10sr-monitor"
+
Example:
resource-manager@0 {
@@ -43,4 +48,8 @@ Example:
gpio-controller;
#gpio-cells = <2>;
};
+
+ a10sr_monitor {
+ compatible = "altr,a10sr-monitor";
+ };
};
--
1.9.1
^ permalink raw reply related
* [PATCHv2 2/4] misc: Add Altera Arria10 System Resource Control
From: tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx @ 2016-10-27 20:00 UTC (permalink / raw)
To: lee.jones-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, arnd-r2nGTMty4D4,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, geert-Td1EMuHUCqxL1ZNQvxDV9g,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Thor Thayer
In-Reply-To: <1477598426-28125-1-git-send-email-tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
From: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
This patch adds the Altera Arria10 control & monitoring
functions to the Arria10 System Resource chip.
Signed-off-by: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
---
v2 Change compatible string and filename from -mon to -monitor
Change CONFIG from module to builtin.
Make wm_rst register writeable.
---
MAINTAINERS | 1 +
drivers/misc/Kconfig | 7 ++
drivers/misc/Makefile | 1 +
drivers/misc/altera-a10sr-monitor.c | 176 ++++++++++++++++++++++++++++++++++++
4 files changed, 185 insertions(+)
create mode 100644 drivers/misc/altera-a10sr-monitor.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 813ea85..1c5b0be 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -631,6 +631,7 @@ M: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
S: Maintained
F: drivers/gpio/gpio-altera-a10sr.c
F: drivers/mfd/altera-a10sr.c
+F: drivers/misc/altera-a10sr-monitor.c
F: include/linux/mfd/altera-a10sr.h
ALTERA TRIPLE SPEED ETHERNET DRIVER
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 64971ba..f42d459 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -766,6 +766,13 @@ config PANEL_BOOT_MESSAGE
An empty message will only clear the display at driver init time. Any other
printf()-formatted message is valid with newline and escape codes.
+config ALTERA_A10SR_MONITOR
+ bool "Altera Arria10 System Resource Monitor"
+ depends on MFD_ALTERA_A10SR
+ help
+ This enables the System Resource monitor driver for the Altera
+ Arria10 DevKit.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 3198336..9f6e77a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -43,6 +43,7 @@ obj-y += ti-st/
obj-y += lis3lv02d/
obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
+obj-$(CONFIG_ALTERA_A10SR_MONITOR) += altera-a10sr-monitor.o
obj-$(CONFIG_INTEL_MEI) += mei/
obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
diff --git a/drivers/misc/altera-a10sr-monitor.c b/drivers/misc/altera-a10sr-monitor.c
new file mode 100644
index 0000000..838ec2c
--- /dev/null
+++ b/drivers/misc/altera-a10sr-monitor.c
@@ -0,0 +1,176 @@
+/*
+ * Altera Arria10 DevKit System Resource Chip Monitor Driver
+ *
+ * Author: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
+ *
+ * Copyright Intel Corporation (C) 2014-2016. All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Monitor driver for the Altera Arria10 MAX5 System Resource Chip
+ * Adapted from ics932s401.c
+ */
+
+#include <linux/err.h>
+#include <linux/mfd/altera-a10sr.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+struct altr_a10sr_regs {
+ struct regmap *regmap;
+ struct attribute_group attr_grp;
+};
+
+static ssize_t a10sr_show(struct device *dev,
+ struct device_attribute *devattr, char *buf);
+static ssize_t a10sr_store(struct device *dev,
+ struct device_attribute *devattr, const char *buf,
+ size_t count);
+
+/* Define FS entries */
+static DEVICE_ATTR(max5_version, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_led, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_button, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_button_irq, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_pg1, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_pg2, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_pg3, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_fmcab, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_hps_resets, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_per_resets, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_sfpa, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_sfpb, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_i2c_master, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_wm_rst, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_wm_rst_key, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_pmbus, 0644, a10sr_show, a10sr_store);
+
+static struct attribute *altr_a10sr_attr[] = {
+ &dev_attr_max5_version.attr,
+ &dev_attr_max5_led.attr,
+ &dev_attr_max5_button.attr,
+ &dev_attr_max5_button_irq.attr,
+ &dev_attr_max5_pg1.attr,
+ &dev_attr_max5_pg2.attr,
+ &dev_attr_max5_pg3.attr,
+ &dev_attr_max5_fmcab.attr,
+ &dev_attr_max5_hps_resets.attr,
+ &dev_attr_max5_per_resets.attr,
+ &dev_attr_max5_sfpa.attr,
+ &dev_attr_max5_sfpb.attr,
+ &dev_attr_max5_i2c_master.attr,
+ &dev_attr_max5_wm_rst.attr,
+ &dev_attr_max5_wm_rst_key.attr,
+ &dev_attr_max5_pmbus.attr,
+ NULL
+};
+
+static const struct attribute_group a10sr_attr_group = {
+ .attrs = altr_a10sr_attr,
+};
+
+static ssize_t a10sr_show(struct device *dev, struct device_attribute *devattr,
+ char *buf)
+{
+ int i, ret;
+ unsigned int val;
+ struct altr_a10sr_regs *a10sr_regs = dev_get_drvdata(dev);
+
+ for (i = 0; i < ARRAY_SIZE(altr_a10sr_attr); i++) {
+ if (devattr == (struct device_attribute *)altr_a10sr_attr[i])
+ break;
+ }
+
+ if (i >= ARRAY_SIZE(altr_a10sr_attr))
+ return -EINVAL;
+
+ /* Shift because LS bit set by regmap for Read */
+ i <<= 1;
+ ret = regmap_read(a10sr_regs->regmap, i, &val);
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "0x%X\n", val);
+}
+
+static ssize_t a10sr_store(struct device *dev,
+ struct device_attribute *devattr, const char *buf,
+ size_t count)
+{
+ struct altr_a10sr_regs *a10sr_regs = dev_get_drvdata(dev);
+ unsigned long val;
+ int i, ret;
+
+ ret = kstrtol(buf, 0, &val);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < ARRAY_SIZE(altr_a10sr_attr); i++) {
+ if (devattr == (struct device_attribute *)altr_a10sr_attr[i])
+ break;
+ }
+ if (i >= ARRAY_SIZE(altr_a10sr_attr))
+ return -EINVAL;
+
+ /* Shift because LS bit cleared by regmap for Write */
+ i <<= 1;
+ ret = regmap_write(a10sr_regs->regmap, i, val);
+ if (ret < 0)
+ return ret;
+
+ return count;
+}
+
+static int altr_a10sr_regs_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct altr_a10sr_regs *a10regs;
+ struct altr_a10sr *a10sr = dev_get_drvdata(pdev->dev.parent);
+
+ a10regs = devm_kzalloc(&pdev->dev, sizeof(*a10regs), GFP_KERNEL);
+ if (!a10regs)
+ return -ENOMEM;
+
+ a10regs->regmap = a10sr->regmap;
+ a10regs->attr_grp = a10sr_attr_group;
+
+ platform_set_drvdata(pdev, a10regs);
+
+ return sysfs_create_group(&pdev->dev.kobj, &a10sr_attr_group);
+}
+
+static int altr_a10sr_regs_remove(struct platform_device *pdev)
+{
+ struct altr_a10sr_regs *a10regs = platform_get_drvdata(pdev);
+
+ sysfs_remove_group(&pdev->dev.kobj, &a10regs->attr_grp);
+
+ return 0;
+}
+
+static const struct of_device_id altr_a10sr_regs_of_match[] = {
+ { .compatible = "altr,a10sr-monitor" },
+ { },
+};
+
+static struct platform_driver altr_a10sr_regs_driver = {
+ .probe = altr_a10sr_regs_probe,
+ .remove = altr_a10sr_regs_remove,
+ .driver = {
+ .name = "altr_a10sr_monitor",
+ .of_match_table = altr_a10sr_regs_of_match,
+ },
+};
+
+builtin_platform_driver(altr_a10sr_regs_driver);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCHv2 3/4] mfd: altr-a10sr: Add Arria10 SR Monitor
From: tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx @ 2016-10-27 20:00 UTC (permalink / raw)
To: lee.jones-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, arnd-r2nGTMty4D4,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, geert-Td1EMuHUCqxL1ZNQvxDV9g,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Thor Thayer
In-Reply-To: <1477598426-28125-1-git-send-email-tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
From: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
Add the Altera Arria10 DevKit System Resource Monitor functionality
to the MFD device.
Signed-off-by: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
---
v2 Change from -mon to -monitor for clarity
---
drivers/mfd/altera-a10sr.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/mfd/altera-a10sr.c b/drivers/mfd/altera-a10sr.c
index 06e1f7f..30de652 100644
--- a/drivers/mfd/altera-a10sr.c
+++ b/drivers/mfd/altera-a10sr.c
@@ -33,6 +33,10 @@
.name = "altr_a10sr_gpio",
.of_compatible = "altr,a10sr-gpio",
},
+ {
+ .name = "altr_a10sr_monitor",
+ .of_compatible = "altr,a10sr-monitor",
+ },
};
static bool altr_a10sr_reg_readable(struct device *dev, unsigned int reg)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCHv2 4/4] ARM: socfpga: dts: Add Monitor to A10-SR MFD
From: tthayer @ 2016-10-27 20:00 UTC (permalink / raw)
To: lee.jones, robh+dt, mark.rutland, dinguyen, linux, arnd, gregkh
Cc: davem, geert, devicetree, linux-kernel, linux-arm-kernel,
Thor Thayer
In-Reply-To: <1477598426-28125-1-git-send-email-tthayer@opensource.altera.com>
From: Thor Thayer <tthayer@opensource.altera.com>
Add the Monitor functionality to the Arria10 DevKit
System Resource chip.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
---
v2 Change from -mon to -monitor for clarity.
---
arch/arm/boot/dts/socfpga_arria10_socdk.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi b/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
index eb00ae3..61a5f42 100644
--- a/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
@@ -121,6 +121,10 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+ a10sr_monitor {
+ compatible = "altr,a10sr-monitor";
+ };
};
};
--
1.9.1
^ permalink raw reply related
* Re: [alsa-devel] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver
From: Maxime Ripard @ 2016-10-27 20:01 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: devicetree, Linux-ALSA, Dave Airlie, linux-sunxi, Liam Girdwood,
Rob Herring, Chen-Yu Tsai, Mark Brown, dri-devel,
linux-arm-kernel
In-Reply-To: <20161027171325.d68baa5ff51da4921ff8b94d-GANU6spQydw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3255 bytes --]
On Thu, Oct 27, 2016 at 05:13:25PM +0200, Jean-Francois Moine wrote:
> On Mon, 24 Oct 2016 14:34:49 +0200
> Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
> > Hi,
> >
> > On Sun, Oct 23, 2016 at 09:45:03AM +0200, Jean-Francois Moine wrote:
> > > On Sun, 23 Oct 2016 09:33:16 +0800
> > > Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> > >
> > > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > > - it handles the H3
> > > >
> > > > If it's close to sun4i-i2s, you should probably rework that one to support
> > > > the newer SoCs.
> > > >
> > > > > - it creates the sound card (with sun4i-i2s, the sound card is created
> > > > > by the CODECs)
> > > >
> > > > I think this is wrong. I2S is only the DAI. You typically have a separate
> > > > platform driver for the whole card, or just use simple-card.
> > >
> > > An other device is not needed. The layout is simple:
> > > I2S_controller (CPU DAI) <-> HDMI_CODEC (CODEC DAI)
> > > The HDMI CODEC is supported by the HDMI video driver (only one device),
> > > so, it cannot be the card device.
> > > ASoC does not use the CPU DAI device (I2S_controller), so, it is
> > > natural to use it to handle the card.
> >
> > Still, duplicating the driver is not the solution. I agree with
> > Chen-Yu that we want to leverage the driver that is already there.
>
> Hi Maxime and Chen-Yu,
>
> After looking at the sun4i-i2s, I found 2 solutions for re-using its
> code in the DE2 HDMI context:
>
> 1) either to split the sun4i-i2s driver into common I/O functions and
> slave CPU DAI,
>
> 2) or to move the sun4i-i2s into a master CPU DAI.
>
> (
> some explanation about 'master' and 'slave': the master is the
> component the device of which is also the sound card.
> As the sound card uses the 'drvdata' of the device, this drvdata pointer
> cannot be used by the master.
> In the actual implementations:
> - sun4i-i2s
> master: card dev = codec dev, drvdata -> card
> slave: i2s dev (CPU DAI), drvdata -> i2s data
> - sun8i-i2s
> master: card dev = i2s dev (CPU DAI), drvdata -> card
> slave: codec dev (hdmi), drvdata -> codec data (audio/video)
> )
>
> In the case 1, there is no functional change, just a source split.
> The sun8i-i2s will then use the common I/O functions.
>
> In the case 2, the CODECs using the sun4i-i2s would have to move to
> slave CODEC DAI, i.e. the card is created by the sun4i-i2s code.
> In the 4.9, there is only one codec (sun4i-codec), so, the change
> is just to move the card creation and the use of drvdata in both
> codes.
I think you're mistaken. sun4i-codec has nothing to do with the I2S
driver. It's a driver for the (poorly named) Allwinner's Audio Codec
which features it's own DAI and Codec directly into the SoC.
The DAI being different from the I2S one.
However, we want to use any codec driver with the i2s driver,
including those in sound/soc/codecs, and we already have drivers for
them.
So I'm not sure either solution is a good one. Why not just make the
HDMI part a codec itself, and use the i2s driver as the CPU DAI, like
any other codec?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH V2 2/4] mfd: pv88080: MFD core support
From: Linus Walleij @ 2016-10-27 20:11 UTC (permalink / raw)
To: Eric Jeong, Wolfram Sang
Cc: LINUX-KERNEL, Lee Jones, Alexandre Courbot, DEVICETREE,
LINUX-GPIO, Liam Girdwood, Mark Brown, Mark Rutland, Rob Herring,
Support Opensource
In-Reply-To: <6dcaf788e4ebffd5c753e5fc5ae67668f74f7c32.1477530195.git.eric.jeong-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
On Thu, Oct 27, 2016 at 3:03 AM, Eric Jeong
<eric.jeong.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org> wrote:
> From: Eric Jeong <eric.jeong.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
>
> This patch adds supports for PV88080 MFD core device.
>
> It provides communication through the I2C interface.
> It contains the following components:
> - Regulators
> - Configurable GPIOs
>
> Kconfig and Makefile are updated to reflect support for PV88080 PMIC.
>
> Signed-off-by: Eric Jeong <eric.jeong.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
(...)
> drivers/mfd/pv88080-i2c.c | 99 ++++++++++++++++
This looks like a pure I2C driver.
Why is it not in drivers/i2c/busses/i2c-pv88080.c?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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