* [PATCH v3 0/2] iio: adc: hx711: Add IIO driver for AVIA HX711 ADC
From: Andreas Klinger @ 2016-12-14 16:16 UTC (permalink / raw)
To: devicetree, linux-iio
Cc: linux-kernel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
galak, jic23, knaack.h, lars, pmeerw, ak
This series adds IIO driver support for the AVIA HX711 ADC which is
mostly used in weighting cells.
The first patch adds the new DT binding for which a new vendor avia
was also added.
The second patch is the simple IIO driver implemented as ADC.
The protocol is specific to this device and implemented using GPIO's.
Documentation of the chip can be found here:
https://cdn.sparkfun.com/datasheets/Sensors/ForceFlex/hx711_english.pdf
Changes in v3:
moved gain from devicetree to sysfs, according to comment of Lars-Peter
Thanks for reviewing and giving suggestions
* Patch 1: "iio: adc: hx711: Add DT binding for avia,hx711"
- removed property gain
* Patch 2: "iio: adc: hx711: Add IIO driver for AVIA HX711"
- removed property gain from devicetree
- added device attribute (rw) for gain
- support reading from both channels now
Changes in v2:
Lots of updates thanks to Peters review.
* Patch 1: "iio: adc: hx711: Add DT binding for avia,hx711"
- typo
- removed unneded section
* Patch 2: "iio: adc: hx711: Add IIO driver for AVIA HX711"
- updated help text in Kconfig
- removed dead code
- removed unused power management
- reduced channel spec to what is actually used
- added error handling in case reset of chip not possible
Andreas Klinger (2):
iio: adc: hx711: Add DT binding for avia,hx711
iio: adc: hx711: Add IIO driver for AVIA HX711
.../devicetree/bindings/iio/adc/avia-hx711.txt | 16 ++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
drivers/iio/adc/Kconfig | 18 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/hx711.c | 292 +++++++++++++++++++++
5 files changed, 328 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
create mode 100644 drivers/iio/adc/hx711.c
--
2.1.4
^ permalink raw reply
* Re: [PATCH v2 04/11] Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
From: Chen-Yu Tsai @ 2016-12-14 16:12 UTC (permalink / raw)
To: Quentin Schulz
Cc: Mark Rutland, devicetree, open list:THERMAL, linux-kernel,
Sebastian Reichel, Russell King, Chen-Yu Tsai, Rob Herring,
Maxime Ripard, Lee Jones, Thomas Petazzoni, linux-arm-kernel
In-Reply-To: <20161209110419.28981-5-quentin.schulz@free-electrons.com>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> This adds the "x-powers,axp223-usb-power-supply" to the list of
> compatibles for AXP20X VBUS power supply driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
>
> v2:
> - adding small explanation on AXP223 variation compared to the AXP221,
>
> Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> index f1d7bee..ba8d35f 100644
> --- a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> +++ b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> @@ -3,6 +3,11 @@ AXP20x USB power supply
> Required Properties:
> -compatible: One of: "x-powers,axp202-usb-power-supply"
> "x-powers,axp221-usb-power-supply"
> + "x-powers,axp223-usb-power-supply"
> +
> +The AXP223 PMIC shares most of its behaviour with the AXP221 but has slight
> +variations such as the former being able to set the VBUS power supply max
> +current to 100mA, unlike the latter.
I actually wanted this in the commit log, but this works too.
Acked-by: Chen-Yu Tsai <wens@csie.org>
>
> This node is a subnode of the axp20x PMIC.
>
> --
> 2.9.3
>
^ permalink raw reply
* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Bartlomiej Zolnierkiewicz @ 2016-12-14 16:10 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Arjun K V, Krzysztof Kozlowski, Kukjin Kim, Rob Herring,
Mark Rutland, Russell King, Doug Anderson, Andreas Faerber,
Thomas Abraham, Ben Gamari, linux-samsung-soc, linux-arm-kernel,
linux-pm, devicetree, linux-kernel
In-Reply-To: <ee4321d6-dcc9-4de7-c376-6b169d160322@osg.samsung.com>
Hi,
On Wednesday, December 14, 2016 11:40:08 AM Javier Martinez Canillas wrote:
> Hello Bartlomiej,
>
> On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
> >>
> >> Hello Bartlomiej,
> >>
> >> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
> >>>
> >>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
> >>>> Hello Bartlomiej,
> >>>
> >>> Hi,
> >>>
> >>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> >>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> >>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> >>>>> cooling maps to account for new OPPs.
> >>>>>
> >>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
> >>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> >>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >>>>>
> >>>>> Tested on Odroid-XU3 and XU3 Lite.
> >>>>>
> >>>>> Cc: Doug Anderson <dianders@chromium.org>
> >>>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> >>>>> Cc: Andreas Faerber <afaerber@suse.de>
> >>>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
> >>>>> Cc: Ben Gamari <ben@smart-cactus.org>
> >>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>>>> ---
> >>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> >>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> >>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> >>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> >>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
> >>>>>
> >>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> >>>>> @@ -118,7 +118,7 @@
> >>>>> /*
> >>>>> * When reaching cpu_alert3, reduce CPU
> >>>>> * by 2 steps. On Exynos5422/5800 that would
> >>>>> - * be: 1600 MHz and 1100 MHz.
> >>>>> + * (usually) be: 1800 MHz and 1200 MHz.
> >>>>> */
> >>>>> map3 {
> >>>>> trip = <&cpu_alert3>;
> >>>>> @@ -131,16 +131,16 @@
> >>>>>
> >>>>> /*
> >>>>> * When reaching cpu_alert4, reduce CPU
> >>>>> - * further, down to 600 MHz (11 steps for big,
> >>>>> - * 7 steps for LITTLE).
> >>>>> + * further, down to 600 MHz (13 steps for big,
> >>>>> + * 8 steps for LITTLE).
> >>>>> */
> >>>>> - map5 {
> >>>>> + cooling_map5: map5 {
> >>>>> trip = <&cpu_alert4>;
> >>>>> - cooling-device = <&cpu0 3 7>;
> >>>>> + cooling-device = <&cpu0 3 8>;
> >>>>> };
> >>>>> - map6 {
> >>>>> + cooling_map6: map6 {
> >>>>> trip = <&cpu_alert4>;
> >>>>> - cooling-device = <&cpu4 3 11>;
> >>>>> + cooling-device = <&cpu4 3 13>;
> >>>>> };
> >>>>> };
> >>>>> };
> >>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> >>>>> @@ -21,6 +21,23 @@
> >>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> >>>>> };
> >>>>>
> >>>>> +&cluster_a15_opp_table {
> >>>>> + /delete-node/opp@2000000000;
> >>>>> + /delete-node/opp@1900000000;
> >>>>> +};
> >>>>> +
> >>>>> +&cluster_a7_opp_table {
> >>>>> + /delete-node/opp@1400000000;
> >>>>> +};
> >>>>> +
> >>>>
> >>>> I think that a comment in the DTS why these operating points aren't available
> >>>> in this board will make more clear why the nodes are being deleted.
> >>>
> >>> Ok, I will add these comments in the next patch revision.
> >>>
> >>>>> +&cooling_map5 {
> >>>>> + cooling-device = <&cpu0 3 7>;
> >>>>> +};
> >>>>> +
> >>>>> +&cooling_map6 {
> >>>>> + cooling-device = <&cpu4 3 11>;
> >>>>> +};
> >>>>> +
> >>>>> &pwm {
> >>>>> /*
> >>>>> * PWM 0 -- fan
> >>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> @@ -146,6 +146,10 @@
> >>>>> vdd-supply = <&ldo9_reg>;
> >>>>> };
> >>>>>
> >>>>> +&cluster_a7_opp_table {
> >>>>> + /delete-property/opp@1400000000;
> >>>>> +};
> >>>>> +
> >>>>> &cpu0 {
> >>>>> cpu-supply = <&buck2_reg>;
> >>>>> };
> >>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> @@ -24,6 +24,16 @@
> >>>>> };
> >>>>>
> >>>>> &cluster_a15_opp_table {
> >>>>> + opp@2000000000 {
> >>>>> + opp-hz = /bits/ 64 <2000000000>;
> >>>>> + opp-microvolt = <1250000>;
> >>>>> + clock-latency-ns = <140000>;
> >>>>> + };
> >>>>> + opp@1900000000 {
> >>>>> + opp-hz = /bits/ 64 <1900000000>;
> >>>>> + opp-microvolt = <1250000>;
> >>>>> + clock-latency-ns = <140000>;
> >>>>> + };
> >>>>> opp@1700000000 {
> >>>>> opp-microvolt = <1250000>;
> >>>>> };
> >>>>> @@ -85,6 +95,11 @@
> >>>>> };
> >>>>>
> >>>>
> >>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> >>>> INT rail would need to be scaled up as well since there's a maximum voltage
> >>>> difference between the ARM and INT rails before the system becomes unstable:
> >>>>
> >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> >>>> https://lkml.org/lkml/2014/5/2/419
> >>>>
> >>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
> >>>> the maximum voltage skew is between a limit. But that never made to mainline:
> >>>>
> >>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
> >>>> https://lkml.org/lkml/2014/4/29/28
> >>>>
> >>>> Did that change and there's infrastructure in mainline now to cope with that?
> >>>> If that's the case, I think it would be good to mention in the commit message.
> >>>
> >>> I was not aware of this limitation and AFAIK mainline has currently
> >>> no code to handle it. I also cannot find any code to handle this in
> >>
> >> Yes, that's what I thought as well but maybe I was missing something.
> >>
> >>> Hardkernel's vendor kernel for Odroid-XU3 board.
> >>>
> >>> Do you know whether this problem exists also on Exynos5422/5800
> >>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> >>> regulator code also on Exynos5800 SoC based Peach Pi board but was
> >>> the problem actually present on this board?
> >>>
> >>
> >> My understanding is that this problem is present in 5420/5422/5800
> >> but I have no way to confirm this. I'm just guessing from the info
> >> in the ChromiumOS vendor tree.
> >>
> >> If you look at the commit that added the regulator-locker driver,
> >> the test says to be done in a Peach Pi so it seems the problem is
> >> not restricted to only Exynos5420:
> >>
> >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
> >>
> >>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
> >>> (unfortunately Inderpal's email is no longer working). ]
> >>>
> >>
> >> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
> >
> > Abhilash's email is also no longer valid.. :(
> >
>
> Yes, I noticed that as well :(
>
> >>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
> >>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> >>> IOW if the problem exists it is already present in the mainline
> >>> kernel.
> >>>
> >>
> >> Ah, I only looked at your patch and I didn't compare the voltage levels
> >> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
> >>
> >> I wonder if the voltage levels in your patch are correct then, since the
> >> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
> >>
> >> /*
> >> * Default ASV table
> >> */
> >> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
> >> 1362500, /* L0 2100 */
> >> 1312500, /* L1 2000 */
> >> 1275000, /* L2 1900 */
> >> 1225000, /* L3 1800 */
> >> 1200000, /* L4 1700 */
> >>
> >> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
> >
> > I think that the above voltages are original ones for Exynos5420
> > (not for Exynos5422/5800).
> >
>
> In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
> Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
This seems suboptimal (or maybe even incorrect as Exynos5422/5800
SoCs also use different clock divider values for clocks related to
CPU clock than Exynos5420 SoC).
Anyway, I can drop Peach Pi support from my patch for now if you want.
> > The voltages in my patch were taken from Hardkernel's kernel for
> > Odroid-XU3:
> >
> > /*
> > * ASV group voltage table
> > */
> > static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
> > ...
> > 1250000, /* L4 2000 */
> > 1250000, /* L5 1900 */
> > 1250000, /* L6 1800 */
> > ...
> >
> > https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
> >
>
> In general I prefer to use the ChromiumOS tree as a reference instead of the
> HardKernel one, since the former is in a much better shape IMHO.
I generally agree, OTOH Hardkernel's tree is based on Samsung's
vendor trees and additionally it contains all low-level hardware
details for Odroid-XU3 board (not present in ChromiumOS tree).
> I think is worth to check in a kernel tree in http://opensource.samsung.com/
> for a product that's Exynos5422/5800 based.
I've just checked kernel from SM-G900H_LL_Opensource.zip (for Galaxy
S5 which is Exynos5422 based) and it uses 50mV lower voltages for
1.6 GHz - 2.0 GHz OPPs, for the lower frequencies OPPs voltages are
identical to the ones used by HardKernel's tree,
drivers/cpufreq/exynos5422-eagle-cpufreq.c:
/*
* ASV group voltage table
*/
static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
...
1200000, /* L4 2000 */
1200000, /* L5 1900 */
1200000, /* L6 1800 */
1200000, /* L7 1700 */
1200000, /* L8 1600 */
1100000, /* L9 1500 */
1100000, /* L10 1400 */
1100000, /* L11 1300 */
1000000, /* L12 1200 */
1000000, /* L13 1100 */
1000000, /* L14 1000 */
1000000, /* L15 900 */
900000, /* L16 800 */
900000, /* L17 700 */
900000, /* L18 600 */
900000, /* L19 500 */
900000, /* L20 400 */
900000, /* L22 300 */
900000, /* L22 200 */
};
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [PATCH v2 03/11] power: supply: axp20x_usb_power: set min voltage and max current from sysfs
From: Chen-Yu Tsai @ 2016-12-14 15:45 UTC (permalink / raw)
To: Quentin Schulz
Cc: Sebastian Reichel, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Russell King, Maxime Ripard, Lee Jones, open list:THERMAL,
devicetree, linux-kernel, linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <20161209110419.28981-4-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> AXP20X and AXP22X PMICs allow setting the min voltage and max current of
> VBUS power supply. This adds entries in sysfs to allow to do so.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
--
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 v2 02/11] mfd: axp20x: add volatile and writeable reg ranges for VBUS power supply driver
From: Chen-Yu Tsai @ 2016-12-14 15:43 UTC (permalink / raw)
To: Quentin Schulz
Cc: Sebastian Reichel, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Russell King, Maxime Ripard, Lee Jones, open list:THERMAL,
devicetree, linux-kernel, linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <20161209110419.28981-3-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> The X-Powers AXP20X and AXP22X PMICs allow to choose the maximum voltage
> and minimum current delivered by the VBUS power supply.
>
> This adds the register used by the VBUS power supply driver to the range
> of volatile and writeable regs ranges.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>
> added in v2
>
> drivers/mfd/axp20x.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index ba130be..6ee2cc6 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -65,12 +65,14 @@ static const struct regmap_access_table axp152_volatile_table = {
>
> static const struct regmap_range axp20x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
This is already covered by the previous entry.
> regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
> regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
> };
>
> static const struct regmap_range axp20x_volatile_ranges[] = {
> regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_USB_OTG_STATUS),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
And I'm not sure why you specify it as volatile? The PMIC doesn't change any
of the bits in this register on its own.
Same for the AXP22x bits. So basically I think you don't need this patch.
ChenYu
> regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL2),
> regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP20X_ACIN_V_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
> @@ -91,11 +93,13 @@ static const struct regmap_access_table axp20x_volatile_table = {
> /* AXP22x ranges are shared with the AXP809, as they cover the same range */
> static const struct regmap_range axp22x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
> };
>
> static const struct regmap_range axp22x_volatile_ranges[] = {
> regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_PWR_OP_MODE),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP22X_GPIO_STATE, AXP22X_GPIO_STATE),
> regmap_reg_range(AXP20X_FG_RES, AXP20X_FG_RES),
> --
> 2.9.3
>
--
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 v9 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Alan Tull @ 2016-12-14 15:40 UTC (permalink / raw)
To: Moritz Fischer
Cc: Joel Holdsworth, Alan Tull, Rob Herring, Devicetree List,
Linux Kernel Mailing List, linux-spi-u79uwXL29TY76Z2rM5mHXA,
Marek Vašut
In-Reply-To: <CAAtXAHcV+AG4en2U=KB0DeLa6RauC9ndojT=ffj+8hWtzS1o4w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, 9 Dec 2016, Moritz Fischer wrote:
> Joel,
>
> A couple of minor nits below (none of them are real blockers), other
> than that looks good.
>
> On Thu, Dec 8, 2016 at 9:35 PM, Joel Holdsworth
> <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org> wrote:
> > The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
> > and very regular structure, designed for low-cost, high-volume consumer
> > and system applications.
>
> <snip>
>
> > This patch adds support to the FPGA manager for configuring the SRAM of
> > iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite and iCE40
> > UltraPlus devices, through slave SPI.
>
> </snip>
>
> I think just this paragraph would be enough.
With these changes,
Acked-by: Alan Tull <atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
Thanks,
Alan
> >
> > The iCE40 family is notable because it is the first FPGA family to have
> > complete reverse engineered bit-stream documentation for the iCE40LP and
> > iCE40HX devices. Furthermore, there is now a Free Software Verilog
> > synthesis tool-chain: the "IceStorm" tool-chain.
> >
> > This project is the work of Clifford Wolf, who is the maintainer of
> > Yosys Verilog RTL synthesis framework, and Mathias Lasser, with notable
> > contributions from "Cotton Seed", the main author of "arachne-pnr"; a
> > place-and-route tool for iCE40 FPGAs.
> >
> > Having a Free Software synthesis tool-chain offers interesting
> > opportunities for embedded devices that are able reconfigure themselves
> > with open firmware that is generated on the device itself. For example
> > a mobile device might have an application processor with an iCE40 FPGA
> > attached, which implements slave devices, or through which the processor
> > communicates with other devices through the FPGA fabric.
> >
> > A kernel driver for the iCE40 is useful, because in some cases, the FPGA
> > may need to be configured before other devices can be accessed.
> >
> > An example of such a device is the icoBoard; a RaspberryPI HAT which
> > features an iCE40HX8K with a 1 or 8 MBit SRAM and ports for
> > Digilent-compatible PMOD modules. A PMOD module may contain a device
> > with which the kernel communicates, via the FPGA.
> >
> > Signed-off-by: Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
> Modulo nits:
>
> Reviewed-by: Moritz Fischer <moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org>
>
> > ---
> > drivers/fpga/Kconfig | 6 ++
> > drivers/fpga/Makefile | 1 +
> > drivers/fpga/ice40-spi.c | 213 +++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 220 insertions(+)
> > create mode 100644 drivers/fpga/ice40-spi.c
> >
> > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > index ce861a2..967cda4 100644
> > --- a/drivers/fpga/Kconfig
> > +++ b/drivers/fpga/Kconfig
> > @@ -20,6 +20,12 @@ config FPGA_REGION
> > FPGA Regions allow loading FPGA images under control of
> > the Device Tree.
> >
> > +config FPGA_MGR_ICE40_SPI
> > + tristate "Lattice iCE40 SPI"
> > + depends on OF && SPI
> > + help
> > + FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
> > +
> > config FPGA_MGR_SOCFPGA
> > tristate "Altera SOCFPGA FPGA Manager"
> > depends on ARCH_SOCFPGA || COMPILE_TEST
> > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > index 8df07bc..cc0d364 100644
> > --- a/drivers/fpga/Makefile
> > +++ b/drivers/fpga/Makefile
> > @@ -6,6 +6,7 @@
> > obj-$(CONFIG_FPGA) += fpga-mgr.o
> >
> > # FPGA Manager Drivers
> > +obj-$(CONFIG_FPGA_MGR_ICE40_SPI) += ice40-spi.o
> > obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> > obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
> > obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
> > diff --git a/drivers/fpga/ice40-spi.c b/drivers/fpga/ice40-spi.c
> > new file mode 100644
> > index 0000000..3c99859
> > --- /dev/null
> > +++ b/drivers/fpga/ice40-spi.c
> > @@ -0,0 +1,213 @@
> > +/*
> > + * FPGA Manager Driver for Lattice iCE40.
> > + *
> > + * Copyright (c) 2016 Joel Holdsworth
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; version 2 of the License.
> > + *
> > + * This driver adds support to the FPGA manager for configuring the SRAM of
> > + * Lattice iCE40 FPGAs through slave SPI.
> > + */
> > +
> > +#include <linux/fpga/fpga-mgr.h>
> > +#include <linux/gpio/consumer.h>
> > +#include <linux/module.h>
> > +#include <linux/of_gpio.h>
> > +#include <linux/spi/spi.h>
> > +
> > +#define ICE40_SPI_FPGAMGR_RESET_DELAY 1 /* us (>200ns) */
> > +#define ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY 1200 /* us */
> > +
> > +#define ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES DIV_ROUND_UP(49, 8)
> > +
> > +struct ice40_fpga_priv {
> > + struct spi_device *dev;
> > + struct gpio_desc *reset;
> > + struct gpio_desc *cdone;
> > +};
> > +
> > +static enum fpga_mgr_states ice40_fpga_ops_state(struct fpga_manager *mgr)
> > +{
> > + struct ice40_fpga_priv *priv = mgr->priv;
> > +
> > + return gpiod_get_value(priv->cdone) ? FPGA_MGR_STATE_OPERATING :
> > + FPGA_MGR_STATE_UNKNOWN;
> > +}
> > +
> > +static int ice40_fpga_ops_write_init(struct fpga_manager *mgr,
> > + struct fpga_image_info *info,
> > + const char *buf, size_t count)
> > +{
> > + struct ice40_fpga_priv *priv = mgr->priv;
> > + struct spi_device *dev = priv->dev;
> > + struct spi_message message;
> > + struct spi_transfer assert_cs_then_reset_delay = {
> > + .cs_change = 1,
> > + .delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY
> > + };
> > + struct spi_transfer housekeeping_delay_then_release_cs = {
> > + .delay_usecs = ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY
> > + };
> > + int ret;
> > +
> > + if ((info->flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> > + dev_err(&dev->dev,
> > + "Partial reconfiguration is not supported\n");
> > + return -ENOTSUPP;
> > + }
> > +
> > + /* Lock the bus, assert CRESET_B and SS_B and delay >200ns */
> > + spi_bus_lock(dev->master);
> > +
> > + gpiod_set_value(priv->reset, 1);
> > +
> > + spi_message_init(&message);
> > + spi_message_add_tail(&assert_cs_then_reset_delay, &message);
> > + ret = spi_sync_locked(dev, &message);
> > +
> > + /* Come out of reset */
> > + gpiod_set_value(priv->reset, 0);
> > +
> > + /* Abort if the chip-select failed */
> > + if (ret)
> > + goto fail;
> > +
> > + /* Check CDONE is de-asserted i.e. the FPGA is reset */
> > + if (gpiod_get_value(priv->cdone)) {
> > + dev_err(&dev->dev, "Device reset failed, CDONE is asserted\n");
> > + ret = -EIO;
> > + goto fail;
> > + }
> > +
> > + /* Wait for the housekeeping to complete, and release SS_B */
> > + spi_message_init(&message);
> > + spi_message_add_tail(&housekeeping_delay_then_release_cs, &message);
> > + ret = spi_sync_locked(dev, &message);
> > +
> > +fail:
> > + spi_bus_unlock(dev->master);
> > +
> > + return ret;
> > +}
> > +
> > +static int ice40_fpga_ops_write(struct fpga_manager *mgr,
> > + const char *buf, size_t count)
> > +{
> > + struct ice40_fpga_priv *priv = mgr->priv;
> > +
> > + return spi_write(priv->dev, buf, count);
> > +}
> > +
> > +static int ice40_fpga_ops_write_complete(struct fpga_manager *mgr,
> > + struct fpga_image_info *info)
> > +{
> > + struct ice40_fpga_priv *priv = mgr->priv;
> > + struct spi_device *dev = priv->dev;
> > + const u8 padding[ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES] = {0};
> > +
> > + /* Check CDONE is asserted */
> > + if (!gpiod_get_value(priv->cdone)) {
> > + dev_err(&dev->dev,
> > + "CDONE was not asserted after firmware transfer\n");
> > + return -EIO;
> > + }
> > +
> > + /* Send of zero-padding to activate the firmware */
> > + return spi_write(dev, padding, sizeof(padding));
> > +}
> > +
> > +static const struct fpga_manager_ops ice40_fpga_ops = {
> > + .state = ice40_fpga_ops_state,
> > + .write_init = ice40_fpga_ops_write_init,
> > + .write = ice40_fpga_ops_write,
> > + .write_complete = ice40_fpga_ops_write_complete,
> > +};
> > +
> > +static int ice40_fpga_probe(struct spi_device *spi)
> > +{
> > + struct device *dev = &spi->dev;
> > + struct device_node *np = spi->dev.of_node;
> > + struct ice40_fpga_priv *priv;
> > + int ret;
> > +
> > + if (!np) {
> > + dev_err(dev, "No Device Tree entry\n");
> > + return -EINVAL;
> > + }
> > +
> > + priv = devm_kzalloc(&spi->dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + priv->dev = spi;
> > +
> > + /* Check board setup data. */
> > + if (spi->max_speed_hz > 25000000) {
> > + dev_err(dev, "Speed is too high\n");
>
> Speed is too high, maximum speed is X. Maybe make it a ICE40_SPI_MAX_SPEED
> > + return -EINVAL;
> > + }
> > +
> > + if (spi->max_speed_hz < 1000000) {
> > + dev_err(dev, "Speed is too low\n");
>
> Speed is too low, minimum speed is X. Maybe make it a ICE40_SPI_MIN_SPEED
> > + return -EINVAL;
> > + }
> > +
> > + if (spi->mode & SPI_CPHA) {
> > + dev_err(dev, "Bad mode\n");
>
> 'Bad mode, SPI_CPHA not supported' mabye.
> > + return -EINVAL;
> > + }
> > +
> > + /* Set up the GPIOs */
> > + priv->cdone = devm_gpiod_get(dev, "cdone", GPIOD_IN);
> > + if (IS_ERR(priv->cdone)) {
> > + dev_err(dev, "Failed to get CDONE GPIO: %ld\n",
> > + PTR_ERR(priv->cdone));
> > + return -EINVAL;
> > + }
> > +
> > + priv->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> > + if (IS_ERR(priv->reset)) {
> > + dev_err(dev, "Failed to get CRESET_B GPIO: %ld\n",
> > + PTR_ERR(priv->reset));
> > + return -EINVAL;
> > + }
> > +
> > + /* Register with the FPGA manager */
> > + ret = fpga_mgr_register(dev, "Lattice iCE40 FPGA Manager",
> > + &ice40_fpga_ops, priv);
> > + if (ret) {
> > + dev_err(dev, "Unable to register FPGA manager");
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int ice40_fpga_remove(struct spi_device *spi)
> > +{
> > + fpga_mgr_unregister(&spi->dev);
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id ice40_fpga_of_match[] = {
> > + { .compatible = "lattice,ice40-fpga-mgr", },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, ice40_fpga_of_match);
> > +
> > +static struct spi_driver ice40_fpga_driver = {
> > + .probe = ice40_fpga_probe,
> > + .remove = ice40_fpga_remove,
> > + .driver = {
> > + .name = "ice40spi",
> > + .of_match_table = of_match_ptr(ice40_fpga_of_match),
> > + },
> > +};
> > +
> > +module_spi_driver(ice40_fpga_driver);
> > +
> > +MODULE_AUTHOR("Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>");
> > +MODULE_DESCRIPTION("Lattice iCE40 FPGA Manager");
> > +MODULE_LICENSE("GPL v2");
> > --
> > 2.7.4
> >
>
> Thanks,
>
> Moritz
>
> PS: can you also Cc linux-fpga mailing list in the future?
>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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 v2 01/11] power: supply: axp20x_usb_power: use of_device_id data field instead of device_is_compatible
From: Chen-Yu Tsai @ 2016-12-14 15:38 UTC (permalink / raw)
To: Quentin Schulz
Cc: Mark Rutland, devicetree, open list:THERMAL, linux-kernel,
Sebastian Reichel, Russell King, Chen-Yu Tsai, Rob Herring,
Maxime Ripard, Lee Jones, Thomas Petazzoni, linux-arm-kernel
In-Reply-To: <20161209110419.28981-2-quentin.schulz@free-electrons.com>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> This replaces calls to of_device_is_compatible to check data field of
> of_device_id matched when probing the driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
From: Maxime Ripard @ 2016-12-14 15:30 UTC (permalink / raw)
To: Emmanuel Vadot
Cc: robh+dt, mark.rutland, linux, wens, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20161214145724.42745-1-manu@bidouilliste.com>
[-- Attachment #1: Type: text/plain, Size: 559 bytes --]
On Wed, Dec 14, 2016 at 03:57:24PM +0100, Emmanuel Vadot wrote:
> The node name for the power seq pin is mmc2@0 like the mmc2_pins_a one.
> This makes the original node (mmc2_pins_a) scrapped out of the dtb and
> result in a unusable eMMC if U-Boot didn't configured the pins to the
> correct functions.
>
> Changes since v1:
> * Rename the node mmc2-rst-pin
That changelog should be after the ---. Removed it and applied.
Thanks!
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 v2 2/3] power: supply: bq24735-charger: optionally poll the ac-detect gpio
From: Sebastian Reichel @ 2016-12-14 15:10 UTC (permalink / raw)
To: Peter Rosin; +Cc: linux-kernel, Rob Herring, Mark Rutland, linux-pm, devicetree
In-Reply-To: <1481673405-4547-3-git-send-email-peda@axentia.se>
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
Hi,
On Wed, Dec 14, 2016 at 12:56:44AM +0100, Peter Rosin wrote:
> If the ac-detect gpio does not support interrupts, provide a fallback
> to poll the gpio at a configurable interval.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
>
> [...]
>
> + } else if (charger->status_gpio) {
> + ret = of_property_read_u32(client->dev.of_node,
> + "poll-interval",
> + &charger->poll_interval);
Please use device_property_read_u32() instead.
> [...]
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] crypto: brcm: Add Broadcom SPU driver DT entry.
From: Rob (William) Rice @ 2016-12-14 15:00 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Herbert Xu, David S. Miller, Rob Herring,
Mark Rutland, linux-crypto, devicetree, linux-kernel, Ray Jui,
Scott Branden, Jon Mason, bcm-kernel-feedback-list,
Catalin Marinas, Will Deacon, linux-arm-kernel, Steve Lin
In-Reply-To: <201612110810.BEVbRp0B%fengguang.wu@intel.com>
I will rebase to Herbert's latest when I submit v3 to address Mark
Rutland's DT comments (and any others that come in).
Rob
On 12/10/2016 7:14 PM, kbuild test robot wrote:
> Hi Rob,
>
> [auto build test ERROR on cryptodev/master]
> [also build test ERROR on v4.9-rc8]
> [cannot apply to next-20161209]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Rob-Rice/crypto-brcm-DT-documentation-for-Broadcom-SPU-driver/20161202-010038
> base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
> config: arm64-defconfig (attached as .config)
> compiler: aarch64-linux-gnu-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=arm64
>
> All errors (new ones prefixed by >>):
>
>>> ERROR: Input tree has errors, aborting (use -f to force output)
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
From: Emmanuel Vadot @ 2016-12-14 14:57 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Emmanuel Vadot
The node name for the power seq pin is mmc2@0 like the mmc2_pins_a one.
This makes the original node (mmc2_pins_a) scrapped out of the dtb and
result in a unusable eMMC if U-Boot didn't configured the pins to the
correct functions.
Changes since v1:
* Rename the node mmc2-rst-pin
Signed-off-by: Emmanuel Vadot <manu-xXdDKFdH5B3kFDPD4ZthVA@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
index 5ea4915..10d3074 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
@@ -56,7 +56,7 @@
};
&pio {
- mmc2_pins_nrst: mmc2@0 {
+ mmc2_pins_nrst: mmc2-rst-pin {
allwinner,pins = "PC16";
allwinner,function = "gpio_out";
allwinner,drive = <SUN4I_PINCTRL_10_MA>;
--
2.9.2
--
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: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Javier Martinez Canillas @ 2016-12-14 14:40 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Arjun K V, Krzysztof Kozlowski, Kukjin Kim, Rob Herring,
Mark Rutland, Russell King, Doug Anderson, Andreas Faerber,
Thomas Abraham, Ben Gamari, linux-samsung-soc, linux-arm-kernel,
linux-pm, devicetree, linux-kernel
In-Reply-To: <3539351.vsrnVhEgRT@amdc3058>
Hello Bartlomiej,
On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
>>
>> Hello Bartlomiej,
>>
>> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
>>>
>>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>>>> Hello Bartlomiej,
>>>
>>> Hi,
>>>
>>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>>>>> cooling maps to account for new OPPs.
>>>>>
>>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
>>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>>>>>
>>>>> Tested on Odroid-XU3 and XU3 Lite.
>>>>>
>>>>> Cc: Doug Anderson <dianders@chromium.org>
>>>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
>>>>> Cc: Andreas Faerber <afaerber@suse.de>
>>>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
>>>>> Cc: Ben Gamari <ben@smart-cactus.org>
>>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>>>> ---
>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
>>>>>
>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>>>>> @@ -118,7 +118,7 @@
>>>>> /*
>>>>> * When reaching cpu_alert3, reduce CPU
>>>>> * by 2 steps. On Exynos5422/5800 that would
>>>>> - * be: 1600 MHz and 1100 MHz.
>>>>> + * (usually) be: 1800 MHz and 1200 MHz.
>>>>> */
>>>>> map3 {
>>>>> trip = <&cpu_alert3>;
>>>>> @@ -131,16 +131,16 @@
>>>>>
>>>>> /*
>>>>> * When reaching cpu_alert4, reduce CPU
>>>>> - * further, down to 600 MHz (11 steps for big,
>>>>> - * 7 steps for LITTLE).
>>>>> + * further, down to 600 MHz (13 steps for big,
>>>>> + * 8 steps for LITTLE).
>>>>> */
>>>>> - map5 {
>>>>> + cooling_map5: map5 {
>>>>> trip = <&cpu_alert4>;
>>>>> - cooling-device = <&cpu0 3 7>;
>>>>> + cooling-device = <&cpu0 3 8>;
>>>>> };
>>>>> - map6 {
>>>>> + cooling_map6: map6 {
>>>>> trip = <&cpu_alert4>;
>>>>> - cooling-device = <&cpu4 3 11>;
>>>>> + cooling-device = <&cpu4 3 13>;
>>>>> };
>>>>> };
>>>>> };
>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>>>>> @@ -21,6 +21,23 @@
>>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>>>>> };
>>>>>
>>>>> +&cluster_a15_opp_table {
>>>>> + /delete-node/opp@2000000000;
>>>>> + /delete-node/opp@1900000000;
>>>>> +};
>>>>> +
>>>>> +&cluster_a7_opp_table {
>>>>> + /delete-node/opp@1400000000;
>>>>> +};
>>>>> +
>>>>
>>>> I think that a comment in the DTS why these operating points aren't available
>>>> in this board will make more clear why the nodes are being deleted.
>>>
>>> Ok, I will add these comments in the next patch revision.
>>>
>>>>> +&cooling_map5 {
>>>>> + cooling-device = <&cpu0 3 7>;
>>>>> +};
>>>>> +
>>>>> +&cooling_map6 {
>>>>> + cooling-device = <&cpu4 3 11>;
>>>>> +};
>>>>> +
>>>>> &pwm {
>>>>> /*
>>>>> * PWM 0 -- fan
>>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>> @@ -146,6 +146,10 @@
>>>>> vdd-supply = <&ldo9_reg>;
>>>>> };
>>>>>
>>>>> +&cluster_a7_opp_table {
>>>>> + /delete-property/opp@1400000000;
>>>>> +};
>>>>> +
>>>>> &cpu0 {
>>>>> cpu-supply = <&buck2_reg>;
>>>>> };
>>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>> @@ -24,6 +24,16 @@
>>>>> };
>>>>>
>>>>> &cluster_a15_opp_table {
>>>>> + opp@2000000000 {
>>>>> + opp-hz = /bits/ 64 <2000000000>;
>>>>> + opp-microvolt = <1250000>;
>>>>> + clock-latency-ns = <140000>;
>>>>> + };
>>>>> + opp@1900000000 {
>>>>> + opp-hz = /bits/ 64 <1900000000>;
>>>>> + opp-microvolt = <1250000>;
>>>>> + clock-latency-ns = <140000>;
>>>>> + };
>>>>> opp@1700000000 {
>>>>> opp-microvolt = <1250000>;
>>>>> };
>>>>> @@ -85,6 +95,11 @@
>>>>> };
>>>>>
>>>>
>>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>>>> INT rail would need to be scaled up as well since there's a maximum voltage
>>>> difference between the ARM and INT rails before the system becomes unstable:
>>>>
>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>>>> https://lkml.org/lkml/2014/5/2/419
>>>>
>>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>>>> the maximum voltage skew is between a limit. But that never made to mainline:
>>>>
>>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>>>> https://lkml.org/lkml/2014/4/29/28
>>>>
>>>> Did that change and there's infrastructure in mainline now to cope with that?
>>>> If that's the case, I think it would be good to mention in the commit message.
>>>
>>> I was not aware of this limitation and AFAIK mainline has currently
>>> no code to handle it. I also cannot find any code to handle this in
>>
>> Yes, that's what I thought as well but maybe I was missing something.
>>
>>> Hardkernel's vendor kernel for Odroid-XU3 board.
>>>
>>> Do you know whether this problem exists also on Exynos5422/5800
>>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
>>> regulator code also on Exynos5800 SoC based Peach Pi board but was
>>> the problem actually present on this board?
>>>
>>
>> My understanding is that this problem is present in 5420/5422/5800
>> but I have no way to confirm this. I'm just guessing from the info
>> in the ChromiumOS vendor tree.
>>
>> If you look at the commit that added the regulator-locker driver,
>> the test says to be done in a Peach Pi so it seems the problem is
>> not restricted to only Exynos5420:
>>
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
>>
>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>> (unfortunately Inderpal's email is no longer working). ]
>>>
>>
>> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
>
> Abhilash's email is also no longer valid.. :(
>
Yes, I noticed that as well :(
>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>> IOW if the problem exists it is already present in the mainline
>>> kernel.
>>>
>>
>> Ah, I only looked at your patch and I didn't compare the voltage levels
>> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
>>
>> I wonder if the voltage levels in your patch are correct then, since the
>> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
>>
>> /*
>> * Default ASV table
>> */
>> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
>> 1362500, /* L0 2100 */
>> 1312500, /* L1 2000 */
>> 1275000, /* L2 1900 */
>> 1225000, /* L3 1800 */
>> 1200000, /* L4 1700 */
>>
>> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
>
> I think that the above voltages are original ones for Exynos5420
> (not for Exynos5422/5800).
>
In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
> The voltages in my patch were taken from Hardkernel's kernel for
> Odroid-XU3:
>
> /*
> * ASV group voltage table
> */
> static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
> ...
> 1250000, /* L4 2000 */
> 1250000, /* L5 1900 */
> 1250000, /* L6 1800 */
> ...
>
> https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
>
In general I prefer to use the ChromiumOS tree as a reference instead of the
HardKernel one, since the former is in a much better shape IMHO.
I think is worth to check in a kernel tree in http://opensource.samsung.com/
for a product that's Exynos5422/5800 based.
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Bartlomiej Zolnierkiewicz @ 2016-12-14 14:25 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Arjun K V, Krzysztof Kozlowski, Kukjin Kim, Rob Herring,
Mark Rutland, Russell King, Doug Anderson, Andreas Faerber,
Thomas Abraham, Ben Gamari, linux-samsung-soc, linux-arm-kernel,
linux-pm, devicetree, linux-kernel
In-Reply-To: <a3179721-3a0e-651b-f422-c08463aae7e6@osg.samsung.com>
Hi,
On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
>
> Hello Bartlomiej,
>
> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
> >
> > On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
> >> Hello Bartlomiej,
> >
> > Hi,
> >
> >> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> >>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> >>> cooling maps to account for new OPPs.
> >>>
> >>> Since new OPPs are not available on all Exynos5422/5800 boards modify
> >>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> >>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >>>
> >>> Tested on Odroid-XU3 and XU3 Lite.
> >>>
> >>> Cc: Doug Anderson <dianders@chromium.org>
> >>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> >>> Cc: Andreas Faerber <afaerber@suse.de>
> >>> Cc: Thomas Abraham <thomas.ab@samsung.com>
> >>> Cc: Ben Gamari <ben@smart-cactus.org>
> >>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>> ---
> >>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> >>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> >>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> >>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> >>> 4 files changed, 43 insertions(+), 7 deletions(-)
> >>>
> >>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> >>> @@ -118,7 +118,7 @@
> >>> /*
> >>> * When reaching cpu_alert3, reduce CPU
> >>> * by 2 steps. On Exynos5422/5800 that would
> >>> - * be: 1600 MHz and 1100 MHz.
> >>> + * (usually) be: 1800 MHz and 1200 MHz.
> >>> */
> >>> map3 {
> >>> trip = <&cpu_alert3>;
> >>> @@ -131,16 +131,16 @@
> >>>
> >>> /*
> >>> * When reaching cpu_alert4, reduce CPU
> >>> - * further, down to 600 MHz (11 steps for big,
> >>> - * 7 steps for LITTLE).
> >>> + * further, down to 600 MHz (13 steps for big,
> >>> + * 8 steps for LITTLE).
> >>> */
> >>> - map5 {
> >>> + cooling_map5: map5 {
> >>> trip = <&cpu_alert4>;
> >>> - cooling-device = <&cpu0 3 7>;
> >>> + cooling-device = <&cpu0 3 8>;
> >>> };
> >>> - map6 {
> >>> + cooling_map6: map6 {
> >>> trip = <&cpu_alert4>;
> >>> - cooling-device = <&cpu4 3 11>;
> >>> + cooling-device = <&cpu4 3 13>;
> >>> };
> >>> };
> >>> };
> >>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> >>> @@ -21,6 +21,23 @@
> >>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> >>> };
> >>>
> >>> +&cluster_a15_opp_table {
> >>> + /delete-node/opp@2000000000;
> >>> + /delete-node/opp@1900000000;
> >>> +};
> >>> +
> >>> +&cluster_a7_opp_table {
> >>> + /delete-node/opp@1400000000;
> >>> +};
> >>> +
> >>
> >> I think that a comment in the DTS why these operating points aren't available
> >> in this board will make more clear why the nodes are being deleted.
> >
> > Ok, I will add these comments in the next patch revision.
> >
> >>> +&cooling_map5 {
> >>> + cooling-device = <&cpu0 3 7>;
> >>> +};
> >>> +
> >>> +&cooling_map6 {
> >>> + cooling-device = <&cpu4 3 11>;
> >>> +};
> >>> +
> >>> &pwm {
> >>> /*
> >>> * PWM 0 -- fan
> >>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>> @@ -146,6 +146,10 @@
> >>> vdd-supply = <&ldo9_reg>;
> >>> };
> >>>
> >>> +&cluster_a7_opp_table {
> >>> + /delete-property/opp@1400000000;
> >>> +};
> >>> +
> >>> &cpu0 {
> >>> cpu-supply = <&buck2_reg>;
> >>> };
> >>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>> @@ -24,6 +24,16 @@
> >>> };
> >>>
> >>> &cluster_a15_opp_table {
> >>> + opp@2000000000 {
> >>> + opp-hz = /bits/ 64 <2000000000>;
> >>> + opp-microvolt = <1250000>;
> >>> + clock-latency-ns = <140000>;
> >>> + };
> >>> + opp@1900000000 {
> >>> + opp-hz = /bits/ 64 <1900000000>;
> >>> + opp-microvolt = <1250000>;
> >>> + clock-latency-ns = <140000>;
> >>> + };
> >>> opp@1700000000 {
> >>> opp-microvolt = <1250000>;
> >>> };
> >>> @@ -85,6 +95,11 @@
> >>> };
> >>>
> >>
> >> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> >> INT rail would need to be scaled up as well since there's a maximum voltage
> >> difference between the ARM and INT rails before the system becomes unstable:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> >> https://lkml.org/lkml/2014/5/2/419
> >>
> >> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
> >> the maximum voltage skew is between a limit. But that never made to mainline:
> >>
> >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
> >> https://lkml.org/lkml/2014/4/29/28
> >>
> >> Did that change and there's infrastructure in mainline now to cope with that?
> >> If that's the case, I think it would be good to mention in the commit message.
> >
> > I was not aware of this limitation and AFAIK mainline has currently
> > no code to handle it. I also cannot find any code to handle this in
>
> Yes, that's what I thought as well but maybe I was missing something.
>
> > Hardkernel's vendor kernel for Odroid-XU3 board.
> >
> > Do you know whether this problem exists also on Exynos5422/5800
> > SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> > regulator code also on Exynos5800 SoC based Peach Pi board but was
> > the problem actually present on this board?
> >
>
> My understanding is that this problem is present in 5420/5422/5800
> but I have no way to confirm this. I'm just guessing from the info
> in the ChromiumOS vendor tree.
>
> If you look at the commit that added the regulator-locker driver,
> the test says to be done in a Peach Pi so it seems the problem is
> not restricted to only Exynos5420:
>
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
>
> > [ I added Arjun to Cc:, maybe he can help in explaining this issue
> > (unfortunately Inderpal's email is no longer working). ]
> >
>
> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
Abhilash's email is also no longer valid.. :(
> > Please also note that on Exynos5422/5800 SoCs the same ARM rail
> > voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> > IOW if the problem exists it is already present in the mainline
> > kernel.
> >
>
> Ah, I only looked at your patch and I didn't compare the voltage levels
> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
>
> I wonder if the voltage levels in your patch are correct then, since the
> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
>
> /*
> * Default ASV table
> */
> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
> 1362500, /* L0 2100 */
> 1312500, /* L1 2000 */
> 1275000, /* L2 1900 */
> 1225000, /* L3 1800 */
> 1200000, /* L4 1700 */
>
> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
I think that the above voltages are original ones for Exynos5420
(not for Exynos5422/5800).
The voltages in my patch were taken from Hardkernel's kernel for
Odroid-XU3:
/*
* ASV group voltage table
*/
static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
...
1250000, /* L4 2000 */
1250000, /* L5 1900 */
1250000, /* L6 1800 */
...
https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH] dt-bindings: mfd: stm32f429: Add QSPI & DSI constants into DT include file
From: gabriel.fernandez @ 2016-12-14 14:23 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, daniel.thompson, andrea.merello, radoslaw.pietrzyk
Cc: devicetree, amelie.delaunay, kernel, olivier.bideau, linux-kernel,
linux-clk, ludovic.barre, gabriel.fernandez, linux-arm-kernel
From: Gabriel Fernandez <gabriel.fernandez@st.com>
It will be used by clock and reset drivers, and DT bindings.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
include/dt-bindings/mfd/stm32f4-rcc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/dt-bindings/mfd/stm32f4-rcc.h b/include/dt-bindings/mfd/stm32f4-rcc.h
index e98942d..315f6c3 100644
--- a/include/dt-bindings/mfd/stm32f4-rcc.h
+++ b/include/dt-bindings/mfd/stm32f4-rcc.h
@@ -40,6 +40,7 @@
/* AHB3 */
#define STM32F4_RCC_AHB3_FMC 0
+#define STM32F4_RCC_AHB3_QSPI 1
#define STM32F4_AHB3_RESET(bit) (STM32F4_RCC_AHB3_##bit + (0x18 * 8))
#define STM32F4_AHB3_CLOCK(bit) (STM32F4_RCC_AHB3_##bit + (0x38 * 8))
@@ -91,6 +92,7 @@
#define STM32F4_RCC_APB2_SPI6 21
#define STM32F4_RCC_APB2_SAI1 22
#define STM32F4_RCC_APB2_LTDC 26
+#define STM32F4_RCC_APB2_DSI 27
#define STM32F4_APB2_RESET(bit) (STM32F4_RCC_APB2_##bit + (0x24 * 8))
#define STM32F4_APB2_CLOCK(bit) (STM32F4_RCC_APB2_##bit + (0x44 * 8))
--
1.9.1
^ permalink raw reply related
* [PATCH] clk: stm32f4: Use CLK_OF_DECLARE_DRIVER initialization method
From: gabriel.fernandez @ 2016-12-14 14:22 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, daniel.thompson, andrea.merello, radoslaw.pietrzyk
Cc: devicetree, amelie.delaunay, kernel, olivier.bideau, linux-kernel,
linux-clk, ludovic.barre, gabriel.fernandez, linux-arm-kernel
From: Gabriel Fernandez <gabriel.fernandez@st.com>
Clock and reset controller use same compatible strings (same IP).
Since commit 989eafd0b609 ("clk: core: Avoid double initialization of
clocks") the OF core flags clock controllers registered with the
CLK_OF_DECLARE() macro as OF_POPULATED, so platform devices with the same
compatible string will not be registered.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
drivers/clk/clk-stm32f4.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 11174a5..0f5ab9b 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -1325,5 +1325,5 @@ static void __init stm32f4_rcc_init(struct device_node *np)
kfree(clks);
iounmap(base);
}
-CLK_OF_DECLARE(stm32f42xx_rcc, "st,stm32f42xx-rcc", stm32f4_rcc_init);
-CLK_OF_DECLARE(stm32f46xx_rcc, "st,stm32f469-rcc", stm32f4_rcc_init);
+CLK_OF_DECLARE_DRIVER(stm32f42xx_rcc, "st,stm32f42xx-rcc", stm32f4_rcc_init);
+CLK_OF_DECLARE_DRIVER(stm32f46xx_rcc, "st,stm32f469-rcc", stm32f4_rcc_init);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH linux v1 0/4] Seven segment display support
From: Arnd Bergmann @ 2016-12-14 14:15 UTC (permalink / raw)
To: Neil Armstrong
Cc: Greg KH, Thomas Petazzoni, mark.rutland-5wv7dgnIgG8,
Jaghathiswari Rankappagounder Natarajan,
devicetree-u79uwXL29TY76Z2rM5mHXA, openbmc-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, joel-U3u1mxZcP9KHXe+LvDLADg,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <ac324946-41da-c090-a0ca-78155611bb7e-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Wednesday, December 14, 2016 2:12:41 PM CET Neil Armstrong wrote:
> On 12/14/2016 01:56 PM, Greg KH wrote:
> > On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote:
> >> Hello,
> >>
> >> On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder
> >> Natarajan wrote:
> >>
> >>> Documentation for the binding which provides an interface for adding clock,
> >>> data and clear signal GPIO lines to control seven segment display.
> >>>
> >>> The platform device driver provides an API for displaying on two 7-segment
> >>> displays, and implements the required bit-banging. The hardware assumed is
> >>> 74HC164 wired to two 7-segment displays.
> >>>
> >>> The character device driver implements the user-space API for letting a user
> >>> write to two 7-segment displays including any conversion methods necessary
> >>> to map the user input to two 7-segment displays.
> >>>
> >>> Adding clock, data and clear signal GPIO lines in the devicetree to control
> >>> seven segment display on zaius platform.
> >>>
> >>> The platform driver matches on the device tree node; the platform driver also
> >>> initializes the character device.
> >>>
> >>> Tested that the seven segment display works properly by writing to the
> >>> character device file on a EVB AST2500 board which also has 74HC164 wired
> >>> to two 7-segment displays.
> >>
> >> FWIW, I proposed a driver for seven segment displays back in 2013:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.html
> >>
> >> And the feedback from Greg KH was: we don't need a driver for that, do
> >> it from userspace. See:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.html
> >>
> >> So: good luck
> >
> > Did anyone ever write a library for this type of thing?
> >
> > Again, I don't want to see one-off drivers for random devices like this
> > that should be able to all be controlled from userspace in a common
> > manner. Much like we did for fingerprint readers a long long time
> > ago...
> >
> Actually, it's more than a random interface, a lot of SoCs and boards actually have such displays
> and it's a pity to use UIO, sysfs gpio bitbanging and all sort of ugly stuff to only print a few
> characters a simple and clean driver could achieve.
> Some very well known SoCs even have integrated registers to lower the BOM and bypass the need for
> a 74HC164 like component and avoid gpio bit banging.
>
> My personal concern is that you could also need to drive more segments, thus 7-segments
> is too restrictive.
>
> But this driver is well structured, the gpio-bitbanging sub-driver is welcome.
Maybe we can find a way to fit this into the existing drivers/leds/ subsystem?
That already supports blinking, brightness and colour attributes of LEDs,
so could this be extended to support (one of) digit, number, character
or string with a common sysfs attribute and a way to hook up a led driver
to that?
Arnd
--
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/2] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
From: Andrzej Hajda @ 2016-12-14 14:14 UTC (permalink / raw)
To: Hoegeun Kwon, thierry.reding, kgene, krzk
Cc: devicetree, linux-samsung-soc, Donghwa Lee, linux-kernel,
dri-devel, Hyungwon Hwang
In-Reply-To: <1481695445-13088-2-git-send-email-hoegeun.kwon@samsung.com>
On 14.12.2016 07:04, Hoegeun Kwon wrote:
> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
> driver. This panel has 1440x2560 resolution in 5.7-inch physical
> panel in the TM2 device.
>
> Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
> Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Hi Hoegeun Kwon,
Is there a reason to upstream obsolete driver? Current version of the
driver is available at [1]. It differs significantly and contains
multiple fixes and improvements. I guess it still requires some
polishing but it is better base for start.
[1]:
https://review.tizen.org/git/?p=platform/kernel/linux-exynos.git;a=blob;f=drivers/gpu/drm/panel/panel-s6e3ha2.c;hb=refs/heads/tizen
Regards
Andrzej
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
From: Maxime Ripard @ 2016-12-14 14:09 UTC (permalink / raw)
To: Emmanuel Vadot; +Cc: robh+dt, wens, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20161214100856.23735-1-manu@bidouilliste.com>
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]
Hi Emmanuel,
On Wed, Dec 14, 2016 at 11:08:56AM +0100, Emmanuel Vadot wrote:
> The node name for the power seq pin is mmc2@0 like the mmc2_pins_a one.
> This makes the original node (mmc2_pins_a) scrapped out of the dtb and
> result in a unusable eMMC if U-Boot didn't configured the pins to the
> correct functions.
>
> Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> ---
> arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
> index 5ea4915..68cb1b5 100644
> --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
> @@ -56,7 +56,7 @@
> };
>
> &pio {
> - mmc2_pins_nrst: mmc2@0 {
> + mmc2_pins_nrst: mmc2@1 {
That would be even better if you renamed it to something like
mmc2-rst-pin to avoid all future conflicts (for example if we ever add
a second mmc pins groups.
Thanks!
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] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Javier Martinez Canillas @ 2016-12-14 14:06 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz, Arjun K V
Cc: Krzysztof Kozlowski, Kukjin Kim, Rob Herring, Mark Rutland,
Russell King, Doug Anderson, Andreas Faerber, Thomas Abraham,
Ben Gamari, linux-samsung-soc, linux-arm-kernel, linux-pm,
devicetree, linux-kernel, Abhilash Kesavan
In-Reply-To: <2340115.HEG9AYUCMD@amdc3058>
Hello Bartlomiej,
On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
>
> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>> Hello Bartlomiej,
>
> Hi,
>
>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>>> cooling maps to account for new OPPs.
>>>
>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>>>
>>> Tested on Odroid-XU3 and XU3 Lite.
>>>
>>> Cc: Doug Anderson <dianders@chromium.org>
>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
>>> Cc: Andreas Faerber <afaerber@suse.de>
>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
>>> Cc: Ben Gamari <ben@smart-cactus.org>
>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>> ---
>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>>> 4 files changed, 43 insertions(+), 7 deletions(-)
>>>
>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>>> @@ -118,7 +118,7 @@
>>> /*
>>> * When reaching cpu_alert3, reduce CPU
>>> * by 2 steps. On Exynos5422/5800 that would
>>> - * be: 1600 MHz and 1100 MHz.
>>> + * (usually) be: 1800 MHz and 1200 MHz.
>>> */
>>> map3 {
>>> trip = <&cpu_alert3>;
>>> @@ -131,16 +131,16 @@
>>>
>>> /*
>>> * When reaching cpu_alert4, reduce CPU
>>> - * further, down to 600 MHz (11 steps for big,
>>> - * 7 steps for LITTLE).
>>> + * further, down to 600 MHz (13 steps for big,
>>> + * 8 steps for LITTLE).
>>> */
>>> - map5 {
>>> + cooling_map5: map5 {
>>> trip = <&cpu_alert4>;
>>> - cooling-device = <&cpu0 3 7>;
>>> + cooling-device = <&cpu0 3 8>;
>>> };
>>> - map6 {
>>> + cooling_map6: map6 {
>>> trip = <&cpu_alert4>;
>>> - cooling-device = <&cpu4 3 11>;
>>> + cooling-device = <&cpu4 3 13>;
>>> };
>>> };
>>> };
>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>>> @@ -21,6 +21,23 @@
>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>>> };
>>>
>>> +&cluster_a15_opp_table {
>>> + /delete-node/opp@2000000000;
>>> + /delete-node/opp@1900000000;
>>> +};
>>> +
>>> +&cluster_a7_opp_table {
>>> + /delete-node/opp@1400000000;
>>> +};
>>> +
>>
>> I think that a comment in the DTS why these operating points aren't available
>> in this board will make more clear why the nodes are being deleted.
>
> Ok, I will add these comments in the next patch revision.
>
>>> +&cooling_map5 {
>>> + cooling-device = <&cpu0 3 7>;
>>> +};
>>> +
>>> +&cooling_map6 {
>>> + cooling-device = <&cpu4 3 11>;
>>> +};
>>> +
>>> &pwm {
>>> /*
>>> * PWM 0 -- fan
>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>> @@ -146,6 +146,10 @@
>>> vdd-supply = <&ldo9_reg>;
>>> };
>>>
>>> +&cluster_a7_opp_table {
>>> + /delete-property/opp@1400000000;
>>> +};
>>> +
>>> &cpu0 {
>>> cpu-supply = <&buck2_reg>;
>>> };
>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>> @@ -24,6 +24,16 @@
>>> };
>>>
>>> &cluster_a15_opp_table {
>>> + opp@2000000000 {
>>> + opp-hz = /bits/ 64 <2000000000>;
>>> + opp-microvolt = <1250000>;
>>> + clock-latency-ns = <140000>;
>>> + };
>>> + opp@1900000000 {
>>> + opp-hz = /bits/ 64 <1900000000>;
>>> + opp-microvolt = <1250000>;
>>> + clock-latency-ns = <140000>;
>>> + };
>>> opp@1700000000 {
>>> opp-microvolt = <1250000>;
>>> };
>>> @@ -85,6 +95,11 @@
>>> };
>>>
>>
>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>> INT rail would need to be scaled up as well since there's a maximum voltage
>> difference between the ARM and INT rails before the system becomes unstable:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>> https://lkml.org/lkml/2014/5/2/419
>>
>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>> the maximum voltage skew is between a limit. But that never made to mainline:
>>
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>> https://lkml.org/lkml/2014/4/29/28
>>
>> Did that change and there's infrastructure in mainline now to cope with that?
>> If that's the case, I think it would be good to mention in the commit message.
>
> I was not aware of this limitation and AFAIK mainline has currently
> no code to handle it. I also cannot find any code to handle this in
Yes, that's what I thought as well but maybe I was missing something.
> Hardkernel's vendor kernel for Odroid-XU3 board.
>
> Do you know whether this problem exists also on Exynos5422/5800
> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> regulator code also on Exynos5800 SoC based Peach Pi board but was
> the problem actually present on this board?
>
My understanding is that this problem is present in 5420/5422/5800
but I have no way to confirm this. I'm just guessing from the info
in the ChromiumOS vendor tree.
If you look at the commit that added the regulator-locker driver,
the test says to be done in a Peach Pi so it seems the problem is
not restricted to only Exynos5420:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
> [ I added Arjun to Cc:, maybe he can help in explaining this issue
> (unfortunately Inderpal's email is no longer working). ]
>
Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
> Please also note that on Exynos5422/5800 SoCs the same ARM rail
> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> IOW if the problem exists it is already present in the mainline
> kernel.
>
Ah, I only looked at your patch and I didn't compare the voltage levels
in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
I wonder if the voltage levels in your patch are correct then, since the
ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
/*
* Default ASV table
*/
static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
1362500, /* L0 2100 */
1312500, /* L1 2000 */
1275000, /* L2 1900 */
1225000, /* L3 1800 */
1200000, /* L4 1700 */
This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH v4 6/6] [media] rc: add support for IR LEDs driven through SPI
From: Andi Shyti @ 2016-12-14 14:00 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Sean Young, Rob Herring, Mark Rutland,
Richard Purdie, Jacek Anaszewski, Heiner Kallweit
Cc: linux-media, devicetree, linux-leds, linux-kernel, Andi Shyti,
Andi Shyti
In-Reply-To: <20161214140030.28537-1-andi.shyti@samsung.com>
The ir-spi is a simple device driver which supports the
connection between an IR LED and the MOSI line of an SPI device.
The driver, indeed, uses the SPI framework to stream the raw data
provided by userspace through an rc character device. The chardev
is handled by the LIRC framework and its functionality basically
provides:
- write: the driver gets a pulse/space signal and translates it
to a binary signal that will be streamed to the IR led through
the SPI framework.
- set frequency: sets the frequency whith which the data should
be sent. This is handle with ioctl with the
LIRC_SET_SEND_CARRIER flag (as per lirc documentation)
- set duty cycle: this is also handled with ioctl with the
LIRC_SET_SEND_DUTY_CYCLE flag. The driver handles duty cycles
of 50%, 60%, 70%, 75%, 80% and 90%, calculated on 16bit data.
The character device is created under /dev/lircX name, where X is
and ID assigned by the LIRC framework.
Example of usage:
fd = open("/dev/lirc0", O_RDWR);
if (fd < 0)
return -1;
val = 608000;
ret = ioctl(fd, LIRC_SET_SEND_CARRIER, &val);
if (ret < 0)
return -1;
val = 60;
ret = ioctl(fd, LIRC_SET_SEND_DUTY_CYCLE, &val);
if (ret < 0)
return -1;
n = write(fd, buffer, BUF_LEN);
if (n < 0 || n != BUF_LEN)
ret = -1;
close(fd);
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Reviewed-by: Sean Young <sean@mess.org>
---
drivers/media/rc/Kconfig | 9 +++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/ir-spi.c | 199 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 209 insertions(+)
create mode 100644 drivers/media/rc/ir-spi.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 629e8ca..3351e25 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -261,6 +261,15 @@ config IR_REDRAT3
To compile this driver as a module, choose M here: the
module will be called redrat3.
+config IR_SPI
+ tristate "SPI connected IR LED"
+ depends on SPI && LIRC
+ ---help---
+ Say Y if you want to use an IR LED connected through SPI bus.
+
+ To compile this driver as a module, choose M here: the module will be
+ called ir-spi.
+
config IR_STREAMZAP
tristate "Streamzap PC Remote IR Receiver"
depends on USB_ARCH_HAS_HCD
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 3a984ee..938c98b 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
obj-$(CONFIG_IR_ENE) += ene_ir.o
obj-$(CONFIG_IR_REDRAT3) += redrat3.o
obj-$(CONFIG_IR_RX51) += ir-rx51.o
+obj-$(CONFIG_IR_SPI) += ir-spi.o
obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
new file mode 100644
index 0000000..d45c603
--- /dev/null
+++ b/drivers/media/rc/ir-spi.c
@@ -0,0 +1,199 @@
+/*
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Author: Andi Shyti <andi.shyti@samsung.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.
+ *
+ * SPI driven IR LED device driver
+ */
+
+#include <linux/delay.h>
+#include <linux/fs.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of_gpio.h>
+#include <linux/regulator/consumer.h>
+#include <linux/spi/spi.h>
+#include <media/rc-core.h>
+
+#define IR_SPI_DRIVER_NAME "ir-spi"
+
+/* pulse value for different duty cycles */
+#define IR_SPI_PULSE_DC_50 0xff00
+#define IR_SPI_PULSE_DC_60 0xfc00
+#define IR_SPI_PULSE_DC_70 0xf800
+#define IR_SPI_PULSE_DC_75 0xf000
+#define IR_SPI_PULSE_DC_80 0xc000
+#define IR_SPI_PULSE_DC_90 0x8000
+
+#define IR_SPI_DEFAULT_FREQUENCY 38000
+#define IR_SPI_BIT_PER_WORD 8
+#define IR_SPI_MAX_BUFSIZE 4096
+
+struct ir_spi_data {
+ u32 freq;
+ u8 duty_cycle;
+ bool negated;
+
+ u16 tx_buf[IR_SPI_MAX_BUFSIZE];
+ u16 pulse;
+ u16 space;
+
+ struct rc_dev *rc;
+ struct spi_device *spi;
+ struct regulator *regulator;
+};
+
+static int ir_spi_tx(struct rc_dev *dev,
+ unsigned int *buffer, unsigned int count)
+{
+ int i;
+ int ret;
+ unsigned int len = 0;
+ struct ir_spi_data *idata = dev->priv;
+ struct spi_transfer xfer;
+
+ /* convert the pulse/space signal to raw binary signal */
+ for (i = 0; i < count; i++) {
+ int j;
+ u16 val = ((i+1) % 2) ? idata->pulse : idata->space;
+
+ if (len + buffer[i] >= IR_SPI_MAX_BUFSIZE)
+ return -EINVAL;
+
+ /*
+ * the first value in buffer is a pulse, so that 0, 2, 4, ...
+ * contain a pulse duration. On the contrary, 1, 3, 5, ...
+ * contain a space duration.
+ */
+ val = (i % 2) ? idata->space : idata->pulse;
+ for (j = 0; j < buffer[i]; j++)
+ idata->tx_buf[len++] = val;
+ }
+
+ memset(&xfer, 0, sizeof(xfer));
+
+ xfer.speed_hz = idata->freq;
+ xfer.len = len * sizeof(*idata->tx_buf);
+ xfer.tx_buf = idata->tx_buf;
+
+ ret = regulator_enable(idata->regulator);
+ if (ret)
+ return ret;
+
+ ret = spi_sync_transfer(idata->spi, &xfer, 1);
+ if (ret)
+ dev_err(&idata->spi->dev, "unable to deliver the signal\n");
+
+ regulator_disable(idata->regulator);
+
+ return ret ? ret : count;
+}
+
+static int ir_spi_set_tx_carrier(struct rc_dev *dev, u32 carrier)
+{
+ struct ir_spi_data *idata = dev->priv;
+
+ if (!carrier)
+ return -EINVAL;
+
+ idata->freq = carrier;
+
+ return 0;
+}
+
+static int ir_spi_set_duty_cycle(struct rc_dev *dev, u32 duty_cycle)
+{
+ struct ir_spi_data *idata = dev->priv;
+
+ if (duty_cycle >= 90)
+ idata->pulse = IR_SPI_PULSE_DC_90;
+ else if (duty_cycle >= 80)
+ idata->pulse = IR_SPI_PULSE_DC_80;
+ else if (duty_cycle >= 75)
+ idata->pulse = IR_SPI_PULSE_DC_75;
+ else if (duty_cycle >= 70)
+ idata->pulse = IR_SPI_PULSE_DC_70;
+ else if (duty_cycle >= 60)
+ idata->pulse = IR_SPI_PULSE_DC_60;
+ else
+ idata->pulse = IR_SPI_PULSE_DC_50;
+
+ if (idata->negated) {
+ idata->pulse = ~idata->pulse;
+ idata->space = 0xffff;
+ } else {
+ idata->space = 0;
+ }
+
+ return 0;
+}
+
+static int ir_spi_probe(struct spi_device *spi)
+{
+ int ret;
+ u8 dc;
+ struct ir_spi_data *idata;
+
+ idata = devm_kzalloc(&spi->dev, sizeof(*idata), GFP_KERNEL);
+ if (!idata)
+ return -ENOMEM;
+
+ idata->regulator = devm_regulator_get(&spi->dev, "irda_regulator");
+ if (IS_ERR(idata->regulator))
+ return PTR_ERR(idata->regulator);
+
+ idata->rc = devm_rc_allocate_device(&spi->dev, RC_DRIVER_IR_RAW_TX);
+ if (!idata->rc)
+ return -ENOMEM;
+
+ idata->rc->tx_ir = ir_spi_tx;
+ idata->rc->s_tx_carrier = ir_spi_set_tx_carrier;
+ idata->rc->s_tx_duty_cycle = ir_spi_set_duty_cycle;
+ idata->rc->driver_name = IR_SPI_DRIVER_NAME;
+ idata->rc->priv = idata;
+ idata->spi = spi;
+
+ idata->negated = of_property_read_bool(spi->dev.of_node,
+ "led-active-low");
+ ret = of_property_read_u8(spi->dev.of_node, "duty-cycle", &dc);
+ if (ret)
+ dc = 50;
+
+ /* ir_spi_set_duty_cycle cannot fail,
+ * it returns int to be compatible with the
+ * rc->s_tx_duty_cycle function
+ */
+ ir_spi_set_duty_cycle(idata->rc, dc);
+
+ idata->freq = IR_SPI_DEFAULT_FREQUENCY;
+
+ return devm_rc_register_device(&spi->dev, idata->rc);
+}
+
+static int ir_spi_remove(struct spi_device *spi)
+{
+ return 0;
+}
+
+static const struct of_device_id ir_spi_of_match[] = {
+ { .compatible = "ir-spi-led" },
+ {},
+};
+
+static struct spi_driver ir_spi_driver = {
+ .probe = ir_spi_probe,
+ .remove = ir_spi_remove,
+ .driver = {
+ .name = IR_SPI_DRIVER_NAME,
+ .of_match_table = ir_spi_of_match,
+ },
+};
+
+module_spi_driver(ir_spi_driver);
+
+MODULE_AUTHOR("Andi Shyti <andi.shyti@samsung.com>");
+MODULE_DESCRIPTION("SPI IR LED");
+MODULE_LICENSE("GPL v2");
--
2.10.2
^ permalink raw reply related
* [PATCH v4 5/6] Documentation: bindings: add documentation for ir-spi device driver
From: Andi Shyti @ 2016-12-14 14:00 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Sean Young, Rob Herring, Mark Rutland,
Richard Purdie, Jacek Anaszewski, Heiner Kallweit
Cc: linux-media, devicetree, linux-leds, linux-kernel, Andi Shyti,
Andi Shyti
In-Reply-To: <20161214140030.28537-1-andi.shyti@samsung.com>
Document the ir-spi driver's binding which is a IR led driven
through the SPI line.
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Reviewed-by: Sean Young <sean@mess.org>
---
.../devicetree/bindings/leds/irled/spi-ir-led.txt | 29 ++++++++++++++++++++++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt
diff --git a/Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt b/Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt
new file mode 100644
index 0000000..896b699
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt
@@ -0,0 +1,29 @@
+Device tree bindings for IR LED connected through SPI bus which is used as
+remote controller.
+
+The IR LED switch is connected to the MOSI line of the SPI device and the data
+are delivered thourgh that.
+
+Required properties:
+ - compatible: should be "ir-spi-led".
+
+Optional properties:
+ - duty-cycle: 8 bit balue that represents the percentage of one period
+ in which the signal is active. It can be 50, 60, 70, 75, 80 or 90.
+ - led-active-low: boolean value that specifies whether the output is
+ negated with a NOT gate.
+ - power-supply: specifies the power source. It can either be a regulator
+ or a gpio which enables a regulator, i.e. a regulator-fixed as
+ described in
+ Documentation/devicetree/bindings/regulator/fixed-regulator.txt
+
+Example:
+
+ irled@0 {
+ compatible = "ir-spi-led";
+ reg = <0x0>;
+ spi-max-frequency = <5000000>;
+ power-supply = <&vdd_led>;
+ led-active-low;
+ duty-cycle = /bits/ 8 <60>;
+ };
--
2.10.2
^ permalink raw reply related
* [PATCH v4 4/6] [media] rc-ir-raw: do not generate any receiving thread for raw transmitters
From: Andi Shyti @ 2016-12-14 14:00 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Sean Young, Rob Herring, Mark Rutland,
Richard Purdie, Jacek Anaszewski, Heiner Kallweit
Cc: linux-media, devicetree, linux-leds, linux-kernel, Andi Shyti,
Andi Shyti
In-Reply-To: <20161214140030.28537-1-andi.shyti@samsung.com>
Raw IR transmitters do not need any thread listening for
occurring events. Check the driver type before running the
thread.
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Reviewed-by: Sean Young <sean@mess.org>
---
drivers/media/rc/rc-ir-raw.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 1c42a9f..9938e42 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -270,12 +270,19 @@ int ir_raw_event_register(struct rc_dev *dev)
INIT_KFIFO(dev->raw->kfifo);
spin_lock_init(&dev->raw->lock);
- dev->raw->thread = kthread_run(ir_raw_event_thread, dev->raw,
- "rc%u", dev->minor);
- if (IS_ERR(dev->raw->thread)) {
- rc = PTR_ERR(dev->raw->thread);
- goto out;
+ /*
+ * raw transmitters do not need any event registration
+ * because the event is coming from userspace
+ */
+ if (dev->driver_type != RC_DRIVER_IR_RAW_TX) {
+ dev->raw->thread = kthread_run(ir_raw_event_thread, dev->raw,
+ "rc%u", dev->minor);
+
+ if (IS_ERR(dev->raw->thread)) {
+ rc = PTR_ERR(dev->raw->thread);
+ goto out;
+ }
}
mutex_lock(&ir_raw_handler_lock);
--
2.10.2
^ permalink raw reply related
* [PATCH v4 3/6] [media] rc-core: add support for IR raw transmitters
From: Andi Shyti @ 2016-12-14 14:00 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Sean Young, Rob Herring, Mark Rutland,
Richard Purdie, Jacek Anaszewski, Heiner Kallweit
Cc: linux-media, devicetree, linux-leds, linux-kernel, Andi Shyti,
Andi Shyti
In-Reply-To: <20161214140030.28537-1-andi.shyti@samsung.com>
IR raw transmitter driver type is specified in the enum
rc_driver_type as RC_DRIVER_IR_RAW_TX which includes all those
devices that transmit raw stream of bit to a receiver.
The data are provided by userspace applications, therefore they
don't need any input device allocation, but still they need to be
registered as raw devices.
Suggested-by: Sean Young <sean@mess.org>
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Reviewed-by: Sean Young <sean@mess.org>
---
drivers/media/rc/rc-main.c | 42 +++++++++++++++++++++++++-----------------
include/media/rc-core.h | 9 ++++++---
2 files changed, 31 insertions(+), 20 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 59fac96..1ddecca 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1365,20 +1365,24 @@ struct rc_dev *rc_allocate_device(enum rc_driver_type type)
if (!dev)
return NULL;
- dev->input_dev = input_allocate_device();
- if (!dev->input_dev) {
- kfree(dev);
- return NULL;
- }
+ if (type != RC_DRIVER_IR_RAW_TX) {
+ dev->input_dev = input_allocate_device();
+ if (!dev->input_dev) {
+ kfree(dev);
+ return NULL;
+ }
+
+ dev->input_dev->getkeycode = ir_getkeycode;
+ dev->input_dev->setkeycode = ir_setkeycode;
+ input_set_drvdata(dev->input_dev, dev);
- dev->input_dev->getkeycode = ir_getkeycode;
- dev->input_dev->setkeycode = ir_setkeycode;
- input_set_drvdata(dev->input_dev, dev);
+ setup_timer(&dev->timer_keyup, ir_timer_keyup,
+ (unsigned long)dev);
- spin_lock_init(&dev->rc_map.lock);
- spin_lock_init(&dev->keylock);
+ spin_lock_init(&dev->rc_map.lock);
+ spin_lock_init(&dev->keylock);
+ }
mutex_init(&dev->lock);
- setup_timer(&dev->timer_keyup, ir_timer_keyup, (unsigned long)dev);
dev->dev.type = &rc_dev_type;
dev->dev.class = &rc_class;
@@ -1507,7 +1511,7 @@ static int rc_setup_rx_device(struct rc_dev *dev)
static void rc_free_rx_device(struct rc_dev *dev)
{
- if (!dev)
+ if (!dev || dev->driver_type == RC_DRIVER_IR_RAW_TX)
return;
ir_free_table(&dev->rc_map);
@@ -1537,7 +1541,8 @@ int rc_register_device(struct rc_dev *dev)
atomic_set(&dev->initialized, 0);
dev->dev.groups = dev->sysfs_groups;
- dev->sysfs_groups[attr++] = &rc_dev_protocol_attr_grp;
+ if (dev->driver_type != RC_DRIVER_IR_RAW_TX)
+ dev->sysfs_groups[attr++] = &rc_dev_protocol_attr_grp;
if (dev->s_filter)
dev->sysfs_groups[attr++] = &rc_dev_filter_attr_grp;
if (dev->s_wakeup_filter)
@@ -1555,11 +1560,14 @@ int rc_register_device(struct rc_dev *dev)
dev->input_name ?: "Unspecified device", path ?: "N/A");
kfree(path);
- rc = rc_setup_rx_device(dev);
- if (rc)
- goto out_dev;
+ if (dev->driver_type != RC_DRIVER_IR_RAW_TX) {
+ rc = rc_setup_rx_device(dev);
+ if (rc)
+ goto out_dev;
+ }
- if (dev->driver_type == RC_DRIVER_IR_RAW) {
+ if (dev->driver_type == RC_DRIVER_IR_RAW ||
+ dev->driver_type == RC_DRIVER_IR_RAW_TX) {
if (!raw_init) {
request_module_nowait("ir-lirc-codec");
raw_init = true;
diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index ba92c86..e6cb336 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -32,13 +32,16 @@ do { \
/**
* enum rc_driver_type - type of the RC output
*
- * @RC_DRIVER_SCANCODE: Driver or hardware generates a scancode
- * @RC_DRIVER_IR_RAW: Driver or hardware generates pulse/space sequences.
- * It needs a Infra-Red pulse/space decoder
+ * @RC_DRIVER_SCANCODE: Driver or hardware generates a scancode
+ * @RC_DRIVER_IR_RAW: Driver or hardware generates pulse/space sequences.
+ * It needs a Infra-Red pulse/space decoder
+ * @RC_DRIVER_IR_RAW_TX: Device transmitter only,
+ * driver requires pulse/space data sequence.
*/
enum rc_driver_type {
RC_DRIVER_SCANCODE = 0,
RC_DRIVER_IR_RAW,
+ RC_DRIVER_IR_RAW_TX,
};
/**
--
2.10.2
^ permalink raw reply related
* [PATCH v4 2/6] [media] rc-main: split setup and unregister functions
From: Andi Shyti @ 2016-12-14 14:00 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Sean Young, Rob Herring, Mark Rutland,
Richard Purdie, Jacek Anaszewski, Heiner Kallweit
Cc: linux-media, devicetree, linux-leds, linux-kernel, Andi Shyti,
Andi Shyti
In-Reply-To: <20161214140030.28537-1-andi.shyti@samsung.com>
Move the input device allocation, map and protocol handling to
different functions.
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Reviewed-by: Sean Young <sean@mess.org>
---
drivers/media/rc/rc-main.c | 143 +++++++++++++++++++++++++--------------------
1 file changed, 81 insertions(+), 62 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index a6bbceb..59fac96 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1436,16 +1436,12 @@ struct rc_dev *devm_rc_allocate_device(struct device *dev,
}
EXPORT_SYMBOL_GPL(devm_rc_allocate_device);
-int rc_register_device(struct rc_dev *dev)
+static int rc_setup_rx_device(struct rc_dev *dev)
{
- static bool raw_init = false; /* raw decoders loaded? */
- struct rc_map *rc_map;
- const char *path;
- int attr = 0;
- int minor;
int rc;
+ struct rc_map *rc_map;
- if (!dev || !dev->map_name)
+ if (!dev->map_name)
return -EINVAL;
rc_map = rc_map_get(dev->map_name);
@@ -1454,6 +1450,19 @@ int rc_register_device(struct rc_dev *dev)
if (!rc_map || !rc_map->scan || rc_map->size == 0)
return -EINVAL;
+ rc = ir_setkeytable(dev, rc_map);
+ if (rc)
+ return rc;
+
+ if (dev->change_protocol) {
+ u64 rc_type = (1ll << rc_map->rc_type);
+
+ rc = dev->change_protocol(dev, &rc_type);
+ if (rc < 0)
+ goto out_table;
+ dev->enabled_protocols = rc_type;
+ }
+
set_bit(EV_KEY, dev->input_dev->evbit);
set_bit(EV_REP, dev->input_dev->evbit);
set_bit(EV_MSC, dev->input_dev->evbit);
@@ -1463,6 +1472,61 @@ int rc_register_device(struct rc_dev *dev)
if (dev->close)
dev->input_dev->close = ir_close;
+ /*
+ * Default delay of 250ms is too short for some protocols, especially
+ * since the timeout is currently set to 250ms. Increase it to 500ms,
+ * to avoid wrong repetition of the keycodes. Note that this must be
+ * set after the call to input_register_device().
+ */
+ dev->input_dev->rep[REP_DELAY] = 500;
+
+ /*
+ * As a repeat event on protocols like RC-5 and NEC take as long as
+ * 110/114ms, using 33ms as a repeat period is not the right thing
+ * to do.
+ */
+ dev->input_dev->rep[REP_PERIOD] = 125;
+
+ /* rc_open will be called here */
+ rc = input_register_device(dev->input_dev);
+ if (rc)
+ goto out_table;
+
+ dev->input_dev->dev.parent = &dev->dev;
+ memcpy(&dev->input_dev->id, &dev->input_id, sizeof(dev->input_id));
+ dev->input_dev->phys = dev->input_phys;
+ dev->input_dev->name = dev->input_name;
+
+ return 0;
+
+out_table:
+ ir_free_table(&dev->rc_map);
+
+ return rc;
+}
+
+static void rc_free_rx_device(struct rc_dev *dev)
+{
+ if (!dev)
+ return;
+
+ ir_free_table(&dev->rc_map);
+
+ input_unregister_device(dev->input_dev);
+ dev->input_dev = NULL;
+}
+
+int rc_register_device(struct rc_dev *dev)
+{
+ static bool raw_init = false; /* raw decoders loaded? */
+ const char *path;
+ int attr = 0;
+ int minor;
+ int rc;
+
+ if (!dev)
+ return -EINVAL;
+
minor = ida_simple_get(&rc_ida, 0, RC_DEV_MAX, GFP_KERNEL);
if (minor < 0)
return minor;
@@ -1486,39 +1550,15 @@ int rc_register_device(struct rc_dev *dev)
if (rc)
goto out_unlock;
- rc = ir_setkeytable(dev, rc_map);
- if (rc)
- goto out_dev;
-
- dev->input_dev->dev.parent = &dev->dev;
- memcpy(&dev->input_dev->id, &dev->input_id, sizeof(dev->input_id));
- dev->input_dev->phys = dev->input_phys;
- dev->input_dev->name = dev->input_name;
-
- rc = input_register_device(dev->input_dev);
- if (rc)
- goto out_table;
-
- /*
- * Default delay of 250ms is too short for some protocols, especially
- * since the timeout is currently set to 250ms. Increase it to 500ms,
- * to avoid wrong repetition of the keycodes. Note that this must be
- * set after the call to input_register_device().
- */
- dev->input_dev->rep[REP_DELAY] = 500;
-
- /*
- * As a repeat event on protocols like RC-5 and NEC take as long as
- * 110/114ms, using 33ms as a repeat period is not the right thing
- * to do.
- */
- dev->input_dev->rep[REP_PERIOD] = 125;
-
path = kobject_get_path(&dev->dev.kobj, GFP_KERNEL);
dev_info(&dev->dev, "%s as %s\n",
dev->input_name ?: "Unspecified device", path ?: "N/A");
kfree(path);
+ rc = rc_setup_rx_device(dev);
+ if (rc)
+ goto out_dev;
+
if (dev->driver_type == RC_DRIVER_IR_RAW) {
if (!raw_init) {
request_module_nowait("ir-lirc-codec");
@@ -1526,36 +1566,20 @@ int rc_register_device(struct rc_dev *dev)
}
rc = ir_raw_event_register(dev);
if (rc < 0)
- goto out_input;
- }
-
- if (dev->change_protocol) {
- u64 rc_type = (1ll << rc_map->rc_type);
- rc = dev->change_protocol(dev, &rc_type);
- if (rc < 0)
- goto out_raw;
- dev->enabled_protocols = rc_type;
+ goto out_rx;
}
/* Allow the RC sysfs nodes to be accessible */
atomic_set(&dev->initialized, 1);
- IR_dprintk(1, "Registered rc%u (driver: %s, remote: %s, mode %s)\n",
+ IR_dprintk(1, "Registered rc%u (driver: %s)\n",
dev->minor,
- dev->driver_name ? dev->driver_name : "unknown",
- rc_map->name ? rc_map->name : "unknown",
- dev->driver_type == RC_DRIVER_IR_RAW ? "raw" : "cooked");
+ dev->driver_name ? dev->driver_name : "unknown");
return 0;
-out_raw:
- if (dev->driver_type == RC_DRIVER_IR_RAW)
- ir_raw_event_unregister(dev);
-out_input:
- input_unregister_device(dev->input_dev);
- dev->input_dev = NULL;
-out_table:
- ir_free_table(&dev->rc_map);
+out_rx:
+ rc_free_rx_device(dev);
out_dev:
device_del(&dev->dev);
out_unlock:
@@ -1601,12 +1625,7 @@ void rc_unregister_device(struct rc_dev *dev)
if (dev->driver_type == RC_DRIVER_IR_RAW)
ir_raw_event_unregister(dev);
- /* Freeing the table should also call the stop callback */
- ir_free_table(&dev->rc_map);
- IR_dprintk(1, "Freed keycode table\n");
-
- input_unregister_device(dev->input_dev);
- dev->input_dev = NULL;
+ rc_free_rx_device(dev);
device_del(&dev->dev);
--
2.10.2
^ permalink raw reply related
* [PATCH v4 1/6] [media] rc-main: assign driver type during allocation
From: Andi Shyti @ 2016-12-14 14:00 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Sean Young, Rob Herring, Mark Rutland,
Richard Purdie, Jacek Anaszewski, Heiner Kallweit
Cc: linux-media, devicetree, linux-leds, linux-kernel, Andi Shyti,
Andi Shyti
In-Reply-To: <20161214140030.28537-1-andi.shyti@samsung.com>
The driver type can be assigned immediately when an RC device
requests to the framework to allocate the device.
This is an 'enum rc_driver_type' data type and specifies whether
the device is a raw receiver or scancode receiver. The type will
be given as parameter to the rc_allocate_device device.
Change accordingly all the drivers calling rc_allocate_device()
so that the device type is specified during the rc device
allocation. Whenever the device type is not specified, it will be
set as RC_DRIVER_SCANCODE which was the default '0' value.
Suggested-by: Sean Young <sean@mess.org>
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Reviewed-by: Sean Young <sean@mess.org>
---
drivers/hid/hid-picolcd_cir.c | 3 +--
drivers/media/cec/cec-core.c | 3 +--
drivers/media/common/siano/smsir.c | 3 +--
drivers/media/i2c/ir-kbd-i2c.c | 2 +-
drivers/media/pci/bt8xx/bttv-input.c | 2 +-
drivers/media/pci/cx23885/cx23885-input.c | 11 +----------
drivers/media/pci/cx88/cx88-input.c | 3 +--
drivers/media/pci/dm1105/dm1105.c | 3 +--
drivers/media/pci/mantis/mantis_input.c | 2 +-
drivers/media/pci/saa7134/saa7134-input.c | 2 +-
drivers/media/pci/smipcie/smipcie-ir.c | 3 +--
drivers/media/pci/ttpci/budget-ci.c | 2 +-
drivers/media/rc/ati_remote.c | 3 +--
drivers/media/rc/ene_ir.c | 3 +--
drivers/media/rc/fintek-cir.c | 3 +--
drivers/media/rc/gpio-ir-recv.c | 3 +--
drivers/media/rc/igorplugusb.c | 3 +--
drivers/media/rc/iguanair.c | 3 +--
drivers/media/rc/img-ir/img-ir-hw.c | 2 +-
drivers/media/rc/img-ir/img-ir-raw.c | 3 +--
drivers/media/rc/imon.c | 3 +--
drivers/media/rc/ir-hix5hd2.c | 3 +--
drivers/media/rc/ite-cir.c | 3 +--
drivers/media/rc/mceusb.c | 3 +--
drivers/media/rc/meson-ir.c | 3 +--
drivers/media/rc/nuvoton-cir.c | 3 +--
drivers/media/rc/rc-loopback.c | 3 +--
drivers/media/rc/rc-main.c | 9 ++++++---
drivers/media/rc/redrat3.c | 3 +--
drivers/media/rc/serial_ir.c | 3 +--
drivers/media/rc/st_rc.c | 3 +--
drivers/media/rc/streamzap.c | 3 +--
drivers/media/rc/sunxi-cir.c | 3 +--
drivers/media/rc/ttusbir.c | 3 +--
drivers/media/rc/winbond-cir.c | 3 +--
drivers/media/usb/au0828/au0828-input.c | 3 +--
drivers/media/usb/cx231xx/cx231xx-input.c | 2 +-
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 3 +--
drivers/media/usb/dvb-usb/dvb-usb-remote.c | 3 +--
drivers/media/usb/em28xx/em28xx-input.c | 2 +-
drivers/media/usb/tm6000/tm6000-input.c | 3 +--
include/media/rc-core.h | 6 ++++--
42 files changed, 50 insertions(+), 85 deletions(-)
diff --git a/drivers/hid/hid-picolcd_cir.c b/drivers/hid/hid-picolcd_cir.c
index 9628651..38b0ea8 100644
--- a/drivers/hid/hid-picolcd_cir.c
+++ b/drivers/hid/hid-picolcd_cir.c
@@ -108,12 +108,11 @@ int picolcd_init_cir(struct picolcd_data *data, struct hid_report *report)
struct rc_dev *rdev;
int ret = 0;
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rdev)
return -ENOMEM;
rdev->priv = data;
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
rdev->open = picolcd_cir_open;
rdev->close = picolcd_cir_close;
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index b0137e2..09bc0ba 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -244,7 +244,7 @@ struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
#if IS_REACHABLE(CONFIG_RC_CORE)
/* Prepare the RC input device */
- adap->rc = rc_allocate_device();
+ adap->rc = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!adap->rc) {
pr_err("cec-%s: failed to allocate memory for rc_dev\n",
name);
@@ -265,7 +265,6 @@ struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
adap->rc->input_id.product = 0;
adap->rc->input_id.version = 1;
adap->rc->dev.parent = parent;
- adap->rc->driver_type = RC_DRIVER_SCANCODE;
adap->rc->driver_name = CEC_NAME;
adap->rc->allowed_protocols = RC_BIT_CEC;
adap->rc->priv = adap;
diff --git a/drivers/media/common/siano/smsir.c b/drivers/media/common/siano/smsir.c
index 41f2a39..ee30c7b 100644
--- a/drivers/media/common/siano/smsir.c
+++ b/drivers/media/common/siano/smsir.c
@@ -58,7 +58,7 @@ int sms_ir_init(struct smscore_device_t *coredev)
struct rc_dev *dev;
pr_debug("Allocating rc device\n");
- dev = rc_allocate_device();
+ dev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!dev)
return -ENOMEM;
@@ -86,7 +86,6 @@ int sms_ir_init(struct smscore_device_t *coredev)
#endif
dev->priv = coredev;
- dev->driver_type = RC_DRIVER_IR_RAW;
dev->allowed_protocols = RC_BIT_ALL;
dev->map_name = sms_get_board(board_id)->rc_codes;
dev->driver_name = MODULE_NAME;
diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index cede397..5ad5167 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -428,7 +428,7 @@ static int ir_probe(struct i2c_client *client, const struct i2c_device_id *id)
* If platform_data doesn't specify rc_dev, initialize it
* internally
*/
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!rc)
return -ENOMEM;
}
diff --git a/drivers/media/pci/bt8xx/bttv-input.c b/drivers/media/pci/bt8xx/bttv-input.c
index 4da720e..76daec7 100644
--- a/drivers/media/pci/bt8xx/bttv-input.c
+++ b/drivers/media/pci/bt8xx/bttv-input.c
@@ -424,7 +424,7 @@ int bttv_input_init(struct bttv *btv)
return -ENODEV;
ir = kzalloc(sizeof(*ir),GFP_KERNEL);
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!ir || !rc)
goto err_out_free;
diff --git a/drivers/media/pci/cx23885/cx23885-input.c b/drivers/media/pci/cx23885/cx23885-input.c
index 1f092fe..c743317 100644
--- a/drivers/media/pci/cx23885/cx23885-input.c
+++ b/drivers/media/pci/cx23885/cx23885-input.c
@@ -267,7 +267,6 @@ int cx23885_input_init(struct cx23885_dev *dev)
struct cx23885_kernel_ir *kernel_ir;
struct rc_dev *rc;
char *rc_map;
- enum rc_driver_type driver_type;
u64 allowed_protos;
int ret;
@@ -285,28 +284,24 @@ int cx23885_input_init(struct cx23885_dev *dev)
case CX23885_BOARD_HAUPPAUGE_HVR1290:
case CX23885_BOARD_HAUPPAUGE_HVR1250:
/* Integrated CX2388[58] IR controller */
- driver_type = RC_DRIVER_IR_RAW;
allowed_protos = RC_BIT_ALL;
/* The grey Hauppauge RC-5 remote */
rc_map = RC_MAP_HAUPPAUGE;
break;
case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL:
/* Integrated CX23885 IR controller */
- driver_type = RC_DRIVER_IR_RAW;
allowed_protos = RC_BIT_ALL;
/* The grey Terratec remote with orange buttons */
rc_map = RC_MAP_NEC_TERRATEC_CINERGY_XS;
break;
case CX23885_BOARD_TEVII_S470:
/* Integrated CX23885 IR controller */
- driver_type = RC_DRIVER_IR_RAW;
allowed_protos = RC_BIT_ALL;
/* A guess at the remote */
rc_map = RC_MAP_TEVII_NEC;
break;
case CX23885_BOARD_MYGICA_X8507:
/* Integrated CX23885 IR controller */
- driver_type = RC_DRIVER_IR_RAW;
allowed_protos = RC_BIT_ALL;
/* A guess at the remote */
rc_map = RC_MAP_TOTAL_MEDIA_IN_HAND_02;
@@ -314,7 +309,6 @@ int cx23885_input_init(struct cx23885_dev *dev)
case CX23885_BOARD_TBS_6980:
case CX23885_BOARD_TBS_6981:
/* Integrated CX23885 IR controller */
- driver_type = RC_DRIVER_IR_RAW;
allowed_protos = RC_BIT_ALL;
/* A guess at the remote */
rc_map = RC_MAP_TBS_NEC;
@@ -326,13 +320,11 @@ int cx23885_input_init(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_S952:
case CX23885_BOARD_DVBSKY_T982:
/* Integrated CX23885 IR controller */
- driver_type = RC_DRIVER_IR_RAW;
allowed_protos = RC_BIT_ALL;
rc_map = RC_MAP_DVBSKY;
break;
case CX23885_BOARD_TT_CT2_4500_CI:
/* Integrated CX23885 IR controller */
- driver_type = RC_DRIVER_IR_RAW;
allowed_protos = RC_BIT_ALL;
rc_map = RC_MAP_TT_1500;
break;
@@ -352,7 +344,7 @@ int cx23885_input_init(struct cx23885_dev *dev)
pci_name(dev->pci));
/* input device */
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rc) {
ret = -ENOMEM;
goto err_out_free;
@@ -371,7 +363,6 @@ int cx23885_input_init(struct cx23885_dev *dev)
rc->input_id.product = dev->pci->device;
}
rc->dev.parent = &dev->pci->dev;
- rc->driver_type = driver_type;
rc->allowed_protocols = allowed_protos;
rc->priv = kernel_ir;
rc->open = cx23885_input_ir_open;
diff --git a/drivers/media/pci/cx88/cx88-input.c b/drivers/media/pci/cx88/cx88-input.c
index dcfea35..6e9f366e 100644
--- a/drivers/media/pci/cx88/cx88-input.c
+++ b/drivers/media/pci/cx88/cx88-input.c
@@ -276,7 +276,7 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev *pci)
*/
ir = kzalloc(sizeof(*ir), GFP_KERNEL);
- dev = rc_allocate_device();
+ dev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!ir || !dev)
goto err_out_free;
@@ -486,7 +486,6 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev *pci)
dev->scancode_mask = hardware_mask;
if (ir->sampling) {
- dev->driver_type = RC_DRIVER_IR_RAW;
dev->timeout = 10 * 1000 * 1000; /* 10 ms */
} else {
dev->driver_type = RC_DRIVER_SCANCODE;
diff --git a/drivers/media/pci/dm1105/dm1105.c b/drivers/media/pci/dm1105/dm1105.c
index a589aa7..76e07c7 100644
--- a/drivers/media/pci/dm1105/dm1105.c
+++ b/drivers/media/pci/dm1105/dm1105.c
@@ -743,7 +743,7 @@ static int dm1105_ir_init(struct dm1105_dev *dm1105)
struct rc_dev *dev;
int err = -ENOMEM;
- dev = rc_allocate_device();
+ dev = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!dev)
return -ENOMEM;
@@ -752,7 +752,6 @@ static int dm1105_ir_init(struct dm1105_dev *dm1105)
dev->driver_name = MODULE_NAME;
dev->map_name = RC_MAP_DM1105_NEC;
- dev->driver_type = RC_DRIVER_SCANCODE;
dev->input_name = "DVB on-card IR receiver";
dev->input_phys = dm1105->ir.input_phys;
dev->input_id.bustype = BUS_PCI;
diff --git a/drivers/media/pci/mantis/mantis_input.c b/drivers/media/pci/mantis/mantis_input.c
index 7f7f1d4..50d10cb 100644
--- a/drivers/media/pci/mantis/mantis_input.c
+++ b/drivers/media/pci/mantis/mantis_input.c
@@ -39,7 +39,7 @@ int mantis_input_init(struct mantis_pci *mantis)
struct rc_dev *dev;
int err;
- dev = rc_allocate_device();
+ dev = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!dev) {
dprintk(MANTIS_ERROR, 1, "Remote device allocation failed");
err = -ENOMEM;
diff --git a/drivers/media/pci/saa7134/saa7134-input.c b/drivers/media/pci/saa7134/saa7134-input.c
index 823b75e..509caa86 100644
--- a/drivers/media/pci/saa7134/saa7134-input.c
+++ b/drivers/media/pci/saa7134/saa7134-input.c
@@ -846,7 +846,7 @@ int saa7134_input_init1(struct saa7134_dev *dev)
}
ir = kzalloc(sizeof(*ir), GFP_KERNEL);
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!ir || !rc) {
err = -ENOMEM;
goto err_out_free;
diff --git a/drivers/media/pci/smipcie/smipcie-ir.c b/drivers/media/pci/smipcie/smipcie-ir.c
index 826c7c7..d2730c3 100644
--- a/drivers/media/pci/smipcie/smipcie-ir.c
+++ b/drivers/media/pci/smipcie/smipcie-ir.c
@@ -183,7 +183,7 @@ int smi_ir_init(struct smi_dev *dev)
struct rc_dev *rc_dev;
struct smi_rc *ir = &dev->ir;
- rc_dev = rc_allocate_device();
+ rc_dev = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!rc_dev)
return -ENOMEM;
@@ -202,7 +202,6 @@ int smi_ir_init(struct smi_dev *dev)
rc_dev->input_id.product = dev->pci_dev->subsystem_device;
rc_dev->dev.parent = &dev->pci_dev->dev;
- rc_dev->driver_type = RC_DRIVER_SCANCODE;
rc_dev->map_name = dev->info->rc_map;
ir->rc_dev = rc_dev;
diff --git a/drivers/media/pci/ttpci/budget-ci.c b/drivers/media/pci/ttpci/budget-ci.c
index 20ad93b..0c0b733 100644
--- a/drivers/media/pci/ttpci/budget-ci.c
+++ b/drivers/media/pci/ttpci/budget-ci.c
@@ -177,7 +177,7 @@ static int msp430_ir_init(struct budget_ci *budget_ci)
struct rc_dev *dev;
int error;
- dev = rc_allocate_device();
+ dev = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!dev) {
printk(KERN_ERR "budget_ci: IR interface initialisation failed\n");
return -ENOMEM;
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 0884b7d..7d0ee3d 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -764,7 +764,6 @@ static void ati_remote_rc_init(struct ati_remote *ati_remote)
struct rc_dev *rdev = ati_remote->rdev;
rdev->priv = ati_remote;
- rdev->driver_type = RC_DRIVER_SCANCODE;
rdev->allowed_protocols = RC_BIT_OTHER;
rdev->driver_name = "ati_remote";
@@ -851,7 +850,7 @@ static int ati_remote_probe(struct usb_interface *interface,
}
ati_remote = kzalloc(sizeof (struct ati_remote), GFP_KERNEL);
- rc_dev = rc_allocate_device();
+ rc_dev = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!ati_remote || !rc_dev)
goto exit_free_dev_rdev;
diff --git a/drivers/media/rc/ene_ir.c b/drivers/media/rc/ene_ir.c
index bd5512e..3b7275f 100644
--- a/drivers/media/rc/ene_ir.c
+++ b/drivers/media/rc/ene_ir.c
@@ -1012,7 +1012,7 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id)
/* allocate memory */
dev = kzalloc(sizeof(struct ene_device), GFP_KERNEL);
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!dev || !rdev)
goto exit_free_dev_rdev;
@@ -1058,7 +1058,6 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id)
if (!dev->hw_learning_and_tx_capable)
learning_mode_force = false;
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
rdev->priv = dev;
rdev->open = ene_open;
diff --git a/drivers/media/rc/fintek-cir.c b/drivers/media/rc/fintek-cir.c
index ecab69e..df125c2 100644
--- a/drivers/media/rc/fintek-cir.c
+++ b/drivers/media/rc/fintek-cir.c
@@ -492,7 +492,7 @@ static int fintek_probe(struct pnp_dev *pdev, const struct pnp_device_id *dev_id
return ret;
/* input device for IR remote (and tx) */
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rdev)
goto exit_free_dev_rdev;
@@ -534,7 +534,6 @@ static int fintek_probe(struct pnp_dev *pdev, const struct pnp_device_id *dev_id
/* Set up the rc device */
rdev->priv = fintek;
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
rdev->open = fintek_open;
rdev->close = fintek_close;
diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
index 5b63b1f..d5d2152 100644
--- a/drivers/media/rc/gpio-ir-recv.c
+++ b/drivers/media/rc/gpio-ir-recv.c
@@ -143,14 +143,13 @@ static int gpio_ir_recv_probe(struct platform_device *pdev)
if (!gpio_dev)
return -ENOMEM;
- rcdev = rc_allocate_device();
+ rcdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rcdev) {
rc = -ENOMEM;
goto err_allocate_device;
}
rcdev->priv = gpio_dev;
- rcdev->driver_type = RC_DRIVER_IR_RAW;
rcdev->input_name = GPIO_IR_DEVICE_NAME;
rcdev->input_phys = GPIO_IR_DEVICE_NAME "/input0";
rcdev->input_id.bustype = BUS_HOST;
diff --git a/drivers/media/rc/igorplugusb.c b/drivers/media/rc/igorplugusb.c
index 5cf983b..d770a62 100644
--- a/drivers/media/rc/igorplugusb.c
+++ b/drivers/media/rc/igorplugusb.c
@@ -190,7 +190,7 @@ static int igorplugusb_probe(struct usb_interface *intf,
usb_make_path(udev, ir->phys, sizeof(ir->phys));
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rc)
goto fail;
@@ -198,7 +198,6 @@ static int igorplugusb_probe(struct usb_interface *intf,
rc->input_phys = ir->phys;
usb_to_input_id(udev, &rc->input_id);
rc->dev.parent = &intf->dev;
- rc->driver_type = RC_DRIVER_IR_RAW;
/*
* This device can only store 36 pulses + spaces, which is not enough
* for the NEC protocol and many others.
diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
index 5f63454..4cd1e6b 100644
--- a/drivers/media/rc/iguanair.c
+++ b/drivers/media/rc/iguanair.c
@@ -431,7 +431,7 @@ static int iguanair_probe(struct usb_interface *intf,
struct usb_host_interface *idesc;
ir = kzalloc(sizeof(*ir), GFP_KERNEL);
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!ir || !rc) {
ret = -ENOMEM;
goto out;
@@ -494,7 +494,6 @@ static int iguanair_probe(struct usb_interface *intf,
rc->input_phys = ir->phys;
usb_to_input_id(ir->udev, &rc->input_id);
rc->dev.parent = &intf->dev;
- rc->driver_type = RC_DRIVER_IR_RAW;
rc->allowed_protocols = RC_BIT_ALL;
rc->priv = ir;
rc->open = iguanair_open;
diff --git a/drivers/media/rc/img-ir/img-ir-hw.c b/drivers/media/rc/img-ir/img-ir-hw.c
index 7bb71bc..c87ae03 100644
--- a/drivers/media/rc/img-ir/img-ir-hw.c
+++ b/drivers/media/rc/img-ir/img-ir-hw.c
@@ -1071,7 +1071,7 @@ int img_ir_probe_hw(struct img_ir_priv *priv)
}
/* Allocate hardware decoder */
- hw->rdev = rdev = rc_allocate_device();
+ hw->rdev = rdev = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!rdev) {
dev_err(priv->dev, "cannot allocate input device\n");
error = -ENOMEM;
diff --git a/drivers/media/rc/img-ir/img-ir-raw.c b/drivers/media/rc/img-ir/img-ir-raw.c
index 33f37ed..8d2f8e2 100644
--- a/drivers/media/rc/img-ir/img-ir-raw.c
+++ b/drivers/media/rc/img-ir/img-ir-raw.c
@@ -110,7 +110,7 @@ int img_ir_probe_raw(struct img_ir_priv *priv)
setup_timer(&raw->timer, img_ir_echo_timer, (unsigned long)priv);
/* Allocate raw decoder */
- raw->rdev = rdev = rc_allocate_device();
+ raw->rdev = rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rdev) {
dev_err(priv->dev, "cannot allocate raw input device\n");
return -ENOMEM;
@@ -118,7 +118,6 @@ int img_ir_probe_raw(struct img_ir_priv *priv)
rdev->priv = priv;
rdev->map_name = RC_MAP_EMPTY;
rdev->input_name = "IMG Infrared Decoder Raw";
- rdev->driver_type = RC_DRIVER_IR_RAW;
/* Register raw decoder */
error = rc_register_device(rdev);
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 0785a24..4234ae6 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -1939,7 +1939,7 @@ static struct rc_dev *imon_init_rdev(struct imon_context *ictx)
const unsigned char fp_packet[] = { 0x40, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x88 };
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!rdev) {
dev_err(ictx->dev, "remote control dev allocation failed\n");
goto out;
@@ -1957,7 +1957,6 @@ static struct rc_dev *imon_init_rdev(struct imon_context *ictx)
rdev->dev.parent = ictx->dev;
rdev->priv = ictx;
- rdev->driver_type = RC_DRIVER_SCANCODE;
rdev->allowed_protocols = RC_BIT_OTHER | RC_BIT_RC6_MCE; /* iMON PAD or MCE */
rdev->change_protocol = imon_ir_change_protocol;
rdev->driver_name = MOD_NAME;
diff --git a/drivers/media/rc/ir-hix5hd2.c b/drivers/media/rc/ir-hix5hd2.c
index d26907e..dc3b959 100644
--- a/drivers/media/rc/ir-hix5hd2.c
+++ b/drivers/media/rc/ir-hix5hd2.c
@@ -229,7 +229,7 @@ static int hix5hd2_ir_probe(struct platform_device *pdev)
return priv->irq;
}
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rdev)
return -ENOMEM;
@@ -242,7 +242,6 @@ static int hix5hd2_ir_probe(struct platform_device *pdev)
clk_prepare_enable(priv->clock);
priv->rate = clk_get_rate(priv->clock);
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
rdev->priv = priv;
rdev->open = hix5hd2_ir_open;
diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c
index 367b28b..92ed356 100644
--- a/drivers/media/rc/ite-cir.c
+++ b/drivers/media/rc/ite-cir.c
@@ -1470,7 +1470,7 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id
return ret;
/* input device for IR remote (and tx) */
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rdev)
goto exit_free_dev_rdev;
itdev->rdev = rdev;
@@ -1561,7 +1561,6 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id
/* set up ir-core props */
rdev->priv = itdev;
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
rdev->open = ite_open;
rdev->close = ite_close;
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 9bf6917..ebcc82d 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -1181,7 +1181,7 @@ static struct rc_dev *mceusb_init_rc_dev(struct mceusb_dev *ir)
struct rc_dev *rc;
int ret;
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rc) {
dev_err(dev, "remote dev allocation failed");
goto out;
@@ -1201,7 +1201,6 @@ static struct rc_dev *mceusb_init_rc_dev(struct mceusb_dev *ir)
usb_to_input_id(ir->usbdev, &rc->input_id);
rc->dev.parent = dev;
rc->priv = ir;
- rc->driver_type = RC_DRIVER_IR_RAW;
rc->allowed_protocols = RC_BIT_ALL;
rc->timeout = MS_TO_NS(100);
if (!ir->flags.no_tx) {
diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c
index 7eb3f4f..8947dc6 100644
--- a/drivers/media/rc/meson-ir.c
+++ b/drivers/media/rc/meson-ir.c
@@ -131,7 +131,7 @@ static int meson_ir_probe(struct platform_device *pdev)
return ir->irq;
}
- ir->rc = rc_allocate_device();
+ ir->rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!ir->rc) {
dev_err(dev, "failed to allocate rc device\n");
return -ENOMEM;
@@ -144,7 +144,6 @@ static int meson_ir_probe(struct platform_device *pdev)
map_name = of_get_property(node, "linux,rc-map-name", NULL);
ir->rc->map_name = map_name ? map_name : RC_MAP_EMPTY;
ir->rc->dev.parent = dev;
- ir->rc->driver_type = RC_DRIVER_IR_RAW;
ir->rc->allowed_protocols = RC_BIT_ALL;
ir->rc->rx_resolution = US_TO_NS(MESON_TRATE);
ir->rc->timeout = MS_TO_NS(200);
diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index 4b78c89..d4cc880 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -998,7 +998,7 @@ static int nvt_probe(struct pnp_dev *pdev, const struct pnp_device_id *dev_id)
return -ENOMEM;
/* input device for IR remote (and tx) */
- nvt->rdev = devm_rc_allocate_device(&pdev->dev);
+ nvt->rdev = devm_rc_allocate_device(&pdev->dev, RC_DRIVER_IR_RAW);
if (!nvt->rdev)
return -ENOMEM;
rdev = nvt->rdev;
@@ -1061,7 +1061,6 @@ static int nvt_probe(struct pnp_dev *pdev, const struct pnp_device_id *dev_id)
/* Set up the rc device */
rdev->priv = nvt;
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
rdev->open = nvt_open;
rdev->close = nvt_close;
diff --git a/drivers/media/rc/rc-loopback.c b/drivers/media/rc/rc-loopback.c
index 63dace8..36192ac 100644
--- a/drivers/media/rc/rc-loopback.c
+++ b/drivers/media/rc/rc-loopback.c
@@ -181,7 +181,7 @@ static int __init loop_init(void)
struct rc_dev *rc;
int ret;
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rc) {
printk(KERN_ERR DRIVER_NAME ": rc_dev allocation failed\n");
return -ENOMEM;
@@ -194,7 +194,6 @@ static int __init loop_init(void)
rc->driver_name = DRIVER_NAME;
rc->map_name = RC_MAP_EMPTY;
rc->priv = &loopdev;
- rc->driver_type = RC_DRIVER_IR_RAW;
rc->allowed_protocols = RC_BIT_ALL;
rc->timeout = 100 * 1000 * 1000; /* 100 ms */
rc->min_timeout = 1;
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index dedaf38..a6bbceb 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1357,7 +1357,7 @@ static struct device_type rc_dev_type = {
.uevent = rc_dev_uevent,
};
-struct rc_dev *rc_allocate_device(void)
+struct rc_dev *rc_allocate_device(enum rc_driver_type type)
{
struct rc_dev *dev;
@@ -1384,6 +1384,8 @@ struct rc_dev *rc_allocate_device(void)
dev->dev.class = &rc_class;
device_initialize(&dev->dev);
+ dev->driver_type = type;
+
__module_get(THIS_MODULE);
return dev;
}
@@ -1410,7 +1412,8 @@ static void devm_rc_alloc_release(struct device *dev, void *res)
rc_free_device(*(struct rc_dev **)res);
}
-struct rc_dev *devm_rc_allocate_device(struct device *dev)
+struct rc_dev *devm_rc_allocate_device(struct device *dev,
+ enum rc_driver_type type)
{
struct rc_dev **dr, *rc;
@@ -1418,7 +1421,7 @@ struct rc_dev *devm_rc_allocate_device(struct device *dev)
if (!dr)
return NULL;
- rc = rc_allocate_device();
+ rc = rc_allocate_device(type);
if (!rc) {
devres_free(dr);
return NULL;
diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 2784f5d..2b6f828 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -945,7 +945,7 @@ static struct rc_dev *redrat3_init_rc_dev(struct redrat3_dev *rr3)
int ret;
u16 prod = le16_to_cpu(rr3->udev->descriptor.idProduct);
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rc)
return NULL;
@@ -960,7 +960,6 @@ static struct rc_dev *redrat3_init_rc_dev(struct redrat3_dev *rr3)
usb_to_input_id(rr3->udev, &rc->input_id);
rc->dev.parent = dev;
rc->priv = rr3;
- rc->driver_type = RC_DRIVER_IR_RAW;
rc->allowed_protocols = RC_BIT_ALL;
rc->min_timeout = MS_TO_NS(RR3_RX_MIN_TIMEOUT);
rc->max_timeout = MS_TO_NS(RR3_RX_MAX_TIMEOUT);
diff --git a/drivers/media/rc/serial_ir.c b/drivers/media/rc/serial_ir.c
index 436bd58..640acc6 100644
--- a/drivers/media/rc/serial_ir.c
+++ b/drivers/media/rc/serial_ir.c
@@ -738,7 +738,7 @@ static int __init serial_ir_init_module(void)
if (result)
return result;
- rcdev = devm_rc_allocate_device(&serial_ir.pdev->dev);
+ rcdev = devm_rc_allocate_device(&serial_ir.pdev->dev, RC_DRIVER_IR_RAW);
if (!rcdev) {
result = -ENOMEM;
goto serial_cleanup;
@@ -777,7 +777,6 @@ static int __init serial_ir_init_module(void)
rcdev->open = serial_ir_open;
rcdev->close = serial_ir_close;
rcdev->dev.parent = &serial_ir.pdev->dev;
- rcdev->driver_type = RC_DRIVER_IR_RAW;
rcdev->allowed_protocols = RC_BIT_ALL;
rcdev->driver_name = KBUILD_MODNAME;
rcdev->map_name = RC_MAP_RC6_MCE;
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 1fa0c9d..e6f6735 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -235,7 +235,7 @@ static int st_rc_probe(struct platform_device *pdev)
if (!rc_dev)
return -ENOMEM;
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rdev)
return -ENOMEM;
@@ -290,7 +290,6 @@ static int st_rc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, rc_dev);
st_rc_hardware_init(rc_dev);
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
/* rx sampling rate is 10Mhz */
rdev->rx_resolution = 100;
diff --git a/drivers/media/rc/streamzap.c b/drivers/media/rc/streamzap.c
index 53f9b0a..f434e45 100644
--- a/drivers/media/rc/streamzap.c
+++ b/drivers/media/rc/streamzap.c
@@ -291,7 +291,7 @@ static struct rc_dev *streamzap_init_rc_dev(struct streamzap_ir *sz)
struct device *dev = sz->dev;
int ret;
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rdev) {
dev_err(dev, "remote dev allocation failed\n");
goto out;
@@ -308,7 +308,6 @@ static struct rc_dev *streamzap_init_rc_dev(struct streamzap_ir *sz)
usb_to_input_id(sz->usbdev, &rdev->input_id);
rdev->dev.parent = dev;
rdev->priv = sz;
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
rdev->driver_name = DRIVER_NAME;
rdev->map_name = RC_MAP_STREAMZAP;
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index eaadc08..5451f3d 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -212,7 +212,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
goto exit_clkdisable_clk;
}
- ir->rc = rc_allocate_device();
+ ir->rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!ir->rc) {
dev_err(dev, "failed to allocate device\n");
ret = -ENOMEM;
@@ -229,7 +229,6 @@ static int sunxi_ir_probe(struct platform_device *pdev)
ir->map_name = of_get_property(dn, "linux,rc-map-name", NULL);
ir->rc->map_name = ir->map_name ?: RC_MAP_EMPTY;
ir->rc->dev.parent = dev;
- ir->rc->driver_type = RC_DRIVER_IR_RAW;
ir->rc->allowed_protocols = RC_BIT_ALL;
ir->rc->rx_resolution = SUNXI_IR_SAMPLE;
ir->rc->timeout = MS_TO_NS(SUNXI_IR_TIMEOUT);
diff --git a/drivers/media/rc/ttusbir.c b/drivers/media/rc/ttusbir.c
index bc214e2..6ff2cef 100644
--- a/drivers/media/rc/ttusbir.c
+++ b/drivers/media/rc/ttusbir.c
@@ -205,7 +205,7 @@ static int ttusbir_probe(struct usb_interface *intf,
int altsetting = -1;
tt = kzalloc(sizeof(*tt), GFP_KERNEL);
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!tt || !rc) {
ret = -ENOMEM;
goto out;
@@ -317,7 +317,6 @@ static int ttusbir_probe(struct usb_interface *intf,
rc->input_phys = tt->phys;
usb_to_input_id(tt->udev, &rc->input_id);
rc->dev.parent = &intf->dev;
- rc->driver_type = RC_DRIVER_IR_RAW;
rc->allowed_protocols = RC_BIT_ALL;
rc->priv = tt;
rc->driver_name = DRIVER_NAME;
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index 78491ed..bc95d22 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -1059,13 +1059,12 @@ wbcir_probe(struct pnp_dev *device, const struct pnp_device_id *dev_id)
if (err)
goto exit_free_data;
- data->dev = rc_allocate_device();
+ data->dev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!data->dev) {
err = -ENOMEM;
goto exit_unregister_led;
}
- data->dev->driver_type = RC_DRIVER_IR_RAW;
data->dev->driver_name = DRVNAME;
data->dev->input_name = WBCIR_NAME;
data->dev->input_phys = "wbcir/cir0";
diff --git a/drivers/media/usb/au0828/au0828-input.c b/drivers/media/usb/au0828/au0828-input.c
index 1e66e78..9ec919c 100644
--- a/drivers/media/usb/au0828/au0828-input.c
+++ b/drivers/media/usb/au0828/au0828-input.c
@@ -298,7 +298,7 @@ int au0828_rc_register(struct au0828_dev *dev)
return -ENODEV;
ir = kzalloc(sizeof(*ir), GFP_KERNEL);
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!ir || !rc)
goto error;
@@ -343,7 +343,6 @@ int au0828_rc_register(struct au0828_dev *dev)
rc->input_id.product = le16_to_cpu(dev->usbdev->descriptor.idProduct);
rc->dev.parent = &dev->usbdev->dev;
rc->driver_name = "au0828-input";
- rc->driver_type = RC_DRIVER_IR_RAW;
rc->allowed_protocols = RC_BIT_NEC | RC_BIT_NECX | RC_BIT_NEC32 |
RC_BIT_RC5;
diff --git a/drivers/media/usb/cx231xx/cx231xx-input.c b/drivers/media/usb/cx231xx/cx231xx-input.c
index 15d8d1b..6e80f3c 100644
--- a/drivers/media/usb/cx231xx/cx231xx-input.c
+++ b/drivers/media/usb/cx231xx/cx231xx-input.c
@@ -72,7 +72,7 @@ int cx231xx_ir_init(struct cx231xx *dev)
memset(&info, 0, sizeof(struct i2c_board_info));
memset(&dev->init_data, 0, sizeof(dev->init_data));
- dev->init_data.rc_dev = rc_allocate_device();
+ dev->init_data.rc_dev = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!dev->init_data.rc_dev)
return -ENOMEM;
diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
index a8e6624..298c91a 100644
--- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
+++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
@@ -147,7 +147,7 @@ static int dvb_usbv2_remote_init(struct dvb_usb_device *d)
if (!d->rc.map_name)
return 0;
- dev = rc_allocate_device();
+ dev = rc_allocate_device(d->rc.driver_type);
if (!dev) {
ret = -ENOMEM;
goto err;
@@ -162,7 +162,6 @@ static int dvb_usbv2_remote_init(struct dvb_usb_device *d)
/* TODO: likely RC-core should took const char * */
dev->driver_name = (char *) d->props->driver_name;
dev->map_name = d->rc.map_name;
- dev->driver_type = d->rc.driver_type;
dev->allowed_protocols = d->rc.allowed_protos;
dev->change_protocol = d->rc.change_protocol;
dev->priv = d;
diff --git a/drivers/media/usb/dvb-usb/dvb-usb-remote.c b/drivers/media/usb/dvb-usb/dvb-usb-remote.c
index c259f9e..059ded5 100644
--- a/drivers/media/usb/dvb-usb/dvb-usb-remote.c
+++ b/drivers/media/usb/dvb-usb/dvb-usb-remote.c
@@ -265,7 +265,7 @@ static int rc_core_dvb_usb_remote_init(struct dvb_usb_device *d)
int err, rc_interval;
struct rc_dev *dev;
- dev = rc_allocate_device();
+ dev = rc_allocate_device(d->props.rc.core.driver_type);
if (!dev)
return -ENOMEM;
@@ -273,7 +273,6 @@ static int rc_core_dvb_usb_remote_init(struct dvb_usb_device *d)
dev->map_name = d->props.rc.core.rc_codes;
dev->change_protocol = d->props.rc.core.change_protocol;
dev->allowed_protocols = d->props.rc.core.allowed_protos;
- dev->driver_type = d->props.rc.core.driver_type;
usb_to_input_id(d->udev, &dev->input_id);
dev->input_name = "IR-receiver inside an USB DVB receiver";
dev->input_phys = d->rc_phys;
diff --git a/drivers/media/usb/em28xx/em28xx-input.c b/drivers/media/usb/em28xx/em28xx-input.c
index a1904e2..4b0914d 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -717,7 +717,7 @@ static int em28xx_ir_init(struct em28xx *dev)
ir = kzalloc(sizeof(*ir), GFP_KERNEL);
if (!ir)
return -ENOMEM;
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!rc)
goto error;
diff --git a/drivers/media/usb/tm6000/tm6000-input.c b/drivers/media/usb/tm6000/tm6000-input.c
index 26b2ebb..377a69b 100644
--- a/drivers/media/usb/tm6000/tm6000-input.c
+++ b/drivers/media/usb/tm6000/tm6000-input.c
@@ -429,7 +429,7 @@ int tm6000_ir_init(struct tm6000_core *dev)
return 0;
ir = kzalloc(sizeof(*ir), GFP_ATOMIC);
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!ir || !rc)
goto out;
@@ -456,7 +456,6 @@ int tm6000_ir_init(struct tm6000_core *dev)
ir->polling = 50;
INIT_DELAYED_WORK(&ir->work, tm6000_ir_handle_key);
}
- rc->driver_type = RC_DRIVER_SCANCODE;
snprintf(ir->name, sizeof(ir->name), "tm5600/60x0 IR (%s)",
dev->name);
diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index 55281b9..ba92c86 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -200,17 +200,19 @@ struct rc_dev {
/**
* rc_allocate_device - Allocates a RC device
*
+ * @rc_driver_type: specifies the type of the RC output to be allocated
* returns a pointer to struct rc_dev.
*/
-struct rc_dev *rc_allocate_device(void);
+struct rc_dev *rc_allocate_device(enum rc_driver_type);
/**
* devm_rc_allocate_device - Managed RC device allocation
*
* @dev: pointer to struct device
+ * @rc_driver_type: specifies the type of the RC output to be allocated
* returns a pointer to struct rc_dev.
*/
-struct rc_dev *devm_rc_allocate_device(struct device *dev);
+struct rc_dev *devm_rc_allocate_device(struct device *dev, enum rc_driver_type);
/**
* rc_free_device - Frees a RC device
--
2.10.2
^ permalink raw reply related
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