[PATCH linux v6 1/2] Documentation: dt-bindings: Document bindings for ASPEED AST2400/AST2500 PWM and Fan tach controller device driver
This binding provides interface for adding values related to ASPEED
AST2400/2500 PWM and Fan tach controller support.
The PWM controller can support upto 8 PWM output ports.
The Fan tach controller can support upto 16 tachometer inputs.
Signed-off-by: Jaghathiswari Rankappagounder Natarajan
---
v6:
- Changed to aspeed,fan-tach-ch
v5:
- Changed the naming scheme to aspeed,ast2400/2500-pwm-tacho
- Removed gpio pin muxing
- Added aspeed vendor prefix for fan-tach-ch
- Changed to fan@0/1
- Changed reg to 32 bits
v4:
- Used 'reg'
v3:
- Made the structure more common
v2:
- Removed '_' in node and property names
- Gave some explanation for the properties used
.../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 68 ++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
diff --git a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
new file mode 100644
index ..ac0a69ab0755
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
@@ -0,0 +1,68 @@
+ASPEED AST2400/AST2500 PWM and Fan Tacho controller device driver
+
+The ASPEED PWM controller can support upto 8 PWM outputs. The ASPEED Fan Tacho
+controller can support upto 16 Fan tachometer inputs.
+
+There can be upto 8 fans supported. Each fan can have one PWM output and
+one/two Fan tach inputs.
+
+Required properties for pwm-tacho node:
+- #address-cells : should be 1.
+
+- #size-cells : should be 1.
+
+- reg : address and length of the register set for the device.
+
+- pinctrl-names : a pinctrl state named "default" must be defined.
+
+- pinctrl-0 : phandle referencing pin configuration of the PWM ports.
+
+- compatible : should be "aspeed,ast2400-pwm-tacho" for AST2400 and
+ "aspeed,ast2500-pwm-tacho" for AST2500.
+
+- clocks : a fixed clock providing input clock frequency(PWM
+ and Fan Tach clock)
+
+fan subnode format:
+===
+Under fan subnode there can upto 8 child nodes, with each child node
+representing a fan. If there are 8 fans each fan can have one PWM port and
+one/two Fan tach inputs.
+
+Required properties for each child node:
+- reg : should specify PWM source port.
+ integer value in the range 0 to 7 with 0 indicating PWM port A and
+ 7 indicating PWM port H.
+
+- aspeed,fan-tach-ch : should specify the Fan tach input channel.
+integer value in the range 0 through 15, with 0 indicating
+ Fan tach channel 0 and 15 indicating Fan tach channel 15.
+ Atleast one Fan tach input channel is required.
+
+Examples:
+
+pwm_tacho_fixed_clk: fixedclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2400>;
+}
+
+pwm_tacho: pwmtachocontroller@1e786000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x1E786000 0x1000>;
+ compatible = "aspeed,ast2500-pwm-tacho";
+ clocks = <&pwm_tacho_fixed_clk>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm0_default &pinctrl_pwm1_default>;
+
+ fan@0 {
+ reg = <0x00>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x00>;
+ };
+
+ fan@1 {
+ reg = <0x01>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x01 0x02>;
+ };
+};
--
2.12.2.715.g7642488e1d-goog
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH linux v6 0/2] Support for ASPEED AST2400/AST2500 PWM and Fan Tach driver
Support for ASPEED AST2400/AST2500 PWM and Fan Tach driver. Patches based on the upstream tag 4.9. Changes made in Version 4 are indicated in the individual patches. The AST2400/AST2500 PWM controller can support 8 PWM output ports. The AST2400/AST2500 Fan Tach controller can support 16 tachometer inputs. The hwmon driver provides sysfs entries through which the user can configure the duty cycle for the particular PWM output port and read the fan rpm value for the particular tachometer input. Added devicetree binding documentation for AST2400/AST2500 PWM and Fan Tach support. Tested on Zaius board (which has AST2500 chip) and observed that when duty cycle is lowered then the fan speed is lowered and lower fan rpm value( corresponding to the duty cycle) is reported and when the duty cycle is increased then the fan speed increases and higher fan rpm value(corresponding to the duty cycle) is reported. Jaghathiswari Rankappagounder Natarajan (2): Documentation: dt-bindings: Document bindings for ASPEED AST2400/AST2500 PWM and Fan tach controller device driver drivers: hwmon: Support for ASPEED PWM/Fan tach .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 68 ++ Documentation/hwmon/aspeed-pwm-tacho | 22 + drivers/hwmon/Kconfig | 9 + drivers/hwmon/Makefile | 1 + drivers/hwmon/aspeed-pwm-tacho.c | 846 + 5 files changed, 946 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt create mode 100644 Documentation/hwmon/aspeed-pwm-tacho create mode 100644 drivers/hwmon/aspeed-pwm-tacho.c -- 2.12.2.715.g7642488e1d-goog -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH linux v6 2/2] drivers: hwmon: Support for ASPEED PWM/Fan tach
The ASPEED AST2400/2500 PWM controller supports 8 PWM output ports. The ASPEED AST2400/2500 Fan tach controller supports 16 tachometer inputs. The device driver matches on the device tree node. The configuration values are read from the device tree and written to the respective registers. The driver provides a sysfs entries through which the user can configure the duty-cycle value (ranging from 0 to 100 percent) and read the fan tach rpm value. Signed-off-by: Jaghathiswari Rankappagounder Natarajan --- v6 - Corrected odd line breaks - Changed upto to up to - Dropped unrelated changes - Removed struct and used regs pointer directly - Made groups to be null terminated - Made correction in calculation of val/raw_data - Removed else after return - Removed unnecessary continuation lines v5: - Changed the driver to suit the changes in the device tree documentation v4: - Modified this driver to suit the representation in the devicetree v3: - Only sent out device tree documentation; did not send this driver v2: - Used BIT() - Used regmap - Avoided division when raw data is 0 - Removed empty lines between declaration - Removed macros; Used two attribute groups and used is_visible callback - Returned error when properties are undefined - Removed .owner field - Used PTR_ERR_OR_ZERO - Removed explicit of_node_put for child nodes Documentation/hwmon/aspeed-pwm-tacho | 22 + drivers/hwmon/Kconfig| 9 + drivers/hwmon/Makefile | 1 + drivers/hwmon/aspeed-pwm-tacho.c | 846 +++ 4 files changed, 878 insertions(+) create mode 100644 Documentation/hwmon/aspeed-pwm-tacho create mode 100644 drivers/hwmon/aspeed-pwm-tacho.c diff --git a/Documentation/hwmon/aspeed-pwm-tacho b/Documentation/hwmon/aspeed-pwm-tacho new file mode 100644 index ..7cfb34977460 --- /dev/null +++ b/Documentation/hwmon/aspeed-pwm-tacho @@ -0,0 +1,22 @@ +Kernel driver aspeed-pwm-tacho +== + +Supported chips: + ASPEED AST2400/2500 + +Authors: + + +Description: + +This driver implements support for ASPEED AST2400/2500 PWM and Fan Tacho +controller. The PWM controller supports upto 8 PWM outputs. The Fan tacho +controller supports up to 16 tachometer inputs. + +The driver provides the following sensor accesses in sysfs: + +fanX_input ro provide current fan rotation value in RPM as reported + by the fan to the device. + +pwmX rw get or set PWM fan control value. This is an integer + value between 0(off) and 255(full speed). diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 45cef3d2c75c..757b5b0705bf 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -341,6 +341,15 @@ config SENSORS_ASB100 This driver can also be built as a module. If so, the module will be called asb100. +config SENSORS_ASPEED + tristate "ASPEED AST2400/AST2500 PWM and Fan tach driver" + help + This driver provides support for ASPEED AST2400/AST2500 PWM + and Fan Tacho controllers. + + This driver can also be built as a module. If so, the module + will be called aspeed_pwm_tacho. + config SENSORS_ATXP1 tristate "Attansic ATXP1 VID controller" depends on I2C diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index aecf4ba17460..83025cc9bb45 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -46,6 +46,7 @@ obj-$(CONFIG_SENSORS_ADT7475) += adt7475.o obj-$(CONFIG_SENSORS_APPLESMC) += applesmc.o obj-$(CONFIG_SENSORS_ARM_SCPI) += scpi-hwmon.o obj-$(CONFIG_SENSORS_ASC7621) += asc7621.o +obj-$(CONFIG_SENSORS_ASPEED) += aspeed-pwm-tacho.o obj-$(CONFIG_SENSORS_ATXP1)+= atxp1.o obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o obj-$(CONFIG_SENSORS_DA9052_ADC)+= da9052-hwmon.o diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c new file mode 100644 index ..29010ad94208 --- /dev/null +++ b/drivers/hwmon/aspeed-pwm-tacho.c @@ -0,0 +1,846 @@ +/* + * Copyright (c) 2016 Google, Inc + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 or later as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* ASPEED PWM & FAN Tach Register Definition */ +#define ASPEED_PTCR_CTRL 0x00 +#define ASPEED_PTCR_CLK_CTRL 0x04 +#define ASPEED_PTCR_DUTY0_CTRL 0x08 +#define ASPEED_PTCR_DUTY1_CTRL 0x0c +#define ASPEED_PTCR_TYPEM_CTRL 0x10 +#define ASPEED_PTCR_TYPEM_CTRL10x14 +#define ASPEED_PTCR_TYPEN_CTRL 0x18 +#define ASPEED_PTCR_TYPEN_CTRL10x1c +#define ASPEED_PTCR_TACH_SOURCE0x20 +#define A
Re: [PATCH 1/2] Documentation/sphinx: kerneldoc: add "unused-functions"
On Fri, 2017-03-31 at 15:54 +0300, Jani Nikula wrote: > > I'm sure the parameter name could be improved to capture what you > mean better; alas I don't have a suggestion. Yes, that's a fair point - perhaps "functions-not-linked" or something like that. > > Internally this works by collecting (per-file) those functions > > (and enums, structs, doc sections...) that are explicitly used, > > and invoking the kernel-doc script with "-nofunction" later. > > A quick thought that I don't have the time to check now, but should > be checked before merging: Is the order of directive extension > execution deterministic if the Sphinx run is parallelized (sphinx- > build -j)? Is it deterministic within an rst file? Surely it's not > deterministic when called from several rst files? The latter is, > perhaps, acceptable, but the former not. Interesting, TBH I never even considered this. How would I even run it that way? Presumably "make htmldocs" doesn't do this? Sphinx documentation (http://www.sphinx-doc.org/en/stable/extdev/) says this: The setup() function can return a dictionary. This is treated by Sphinx as metadata of the extension. Metadata keys currently recognized are: [...] 'parallel_read_safe': a boolean that specifies if parallel reading of source files can be used when the extension is loaded. It defaults to False, i.e. you have to explicitly specify your extension to be parallel-read-safe after checking that it is. We do set this right now, so I guess it'd only be guaranteed to work right within a single rst file, and then I should perhaps consider not making this state global but somehow linking it to the rst file being processed? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] input: add an EV_REL event for high-res vertical wheel
As some devices can produce either low-res or high-res vertical wheel EV_REL events, add a new event to allow userspace to distinguish between them. Signed-off-by: Mauro Carvalho Chehab --- Documentation/input/event-codes.rst| 16 +--- include/uapi/linux/input-event-codes.h | 1 + 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst index 92db50954169..0c8591d39bc6 100644 --- a/Documentation/input/event-codes.rst +++ b/Documentation/input/event-codes.rst @@ -185,10 +185,20 @@ instead of EV_REL codes. A few EV_REL codes have special meanings: -* REL_WHEEL, REL_HWHEEL: +* REL_WHEEL: - - These codes are used for vertical and horizontal scroll wheels, -respectively. + - These codes are used for vertical scroll wheels. + + - REL_WHEEL is for normal wheel operational mode, e. g. low-resolution +(line-based) scroll. + + - REL_HIRES_WHEEL should be used when the wheel has two resolutions and it +is in high-resolution mode, e. g. the same angular movement that would +produce a single REL_WHEEL will produce multiple REL_HIRES_WHEEL events. + +* REL_HWHEEL: + + - This code is used for horizontal scroll wheels. EV_ABS -- diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h index 3af60ee69053..23b2d377af59 100644 --- a/include/uapi/linux/input-event-codes.h +++ b/include/uapi/linux/input-event-codes.h @@ -703,6 +703,7 @@ #define REL_DIAL 0x07 #define REL_WHEEL 0x08 #define REL_MISC 0x09 +#define REL_HIRES_WHEEL0x0a #define REL_MAX0x0f #define REL_CNT(REL_MAX+1) -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] input: add a EV_SW event for ratchet switch
Some mouses have a switch on their wheel, allowing to switch
between ratchet or free wheel mode. Add support for it.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/input/event-codes.rst| 16
include/linux/mod_devicetable.h| 2 +-
include/uapi/linux/input-event-codes.h | 4 +++-
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/input/event-codes.rst
b/Documentation/input/event-codes.rst
index 0c8591d39bc6..93f14f0ddb3d 100644
--- a/Documentation/input/event-codes.rst
+++ b/Documentation/input/event-codes.rst
@@ -239,6 +239,22 @@ Upon resume, if the switch state is the same as before
suspend, then the input
subsystem will filter out the duplicate switch state reports. The driver does
not need to keep the state of the switch at any time.
+A few EV_SW codes have special meanings:
+
+* SW_RATCHET:
+
+ - Some mouses have a special switch at their wheel that allows to change
+from free wheel mode to ratchet mode.
+
+When such switch is ratchet mode (ON state), the wheel will offer some
+resistance for movements movement. It will also provide a tactile
+feedback when scrolled.
+
+When pressed while in ratchet mode, the wheel will switch to free wheel
+mode (OFF state). In this mode, it will offer no resistance to wheel
+movements nor any tactile feedback. Pressing again returns to ratchet
+mode.
+
EV_MSC
--
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 8a57f0b1242d..73534c591b40 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -292,7 +292,7 @@ struct pcmcia_device_id {
#define INPUT_DEVICE_ID_LED_MAX0x0f
#define INPUT_DEVICE_ID_SND_MAX0x07
#define INPUT_DEVICE_ID_FF_MAX 0x7f
-#define INPUT_DEVICE_ID_SW_MAX 0x0f
+#define INPUT_DEVICE_ID_SW_MAX 0x1f
#define INPUT_DEVICE_ID_MATCH_BUS 1
#define INPUT_DEVICE_ID_MATCH_VENDOR 2
diff --git a/include/uapi/linux/input-event-codes.h
b/include/uapi/linux/input-event-codes.h
index 23b2d377af59..a3eafd0527f1 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -782,7 +782,9 @@
#define SW_LINEIN_INSERT 0x0d /* set = inserted */
#define SW_MUTE_DEVICE 0x0e /* set = device disabled */
#define SW_PEN_INSERTED0x0f /* set = pen inserted */
-#define SW_MAX 0x0f
+#define SW_RATCHET 0x10 /* set = ratchet mode,
+unset: free wheel */
+#define SW_MAX 0x1f
#define SW_CNT (SW_MAX+1)
/*
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] input: add support for high resolution wheel found on some Logitech devices
Some Logitech mouses (MX Anyware 2, MX Master) have a wheel with two resolutions. It initializes in low resolution mode, but can be changed to high resolution. It also supports free wheel mode, where there's no tactile feedback at the wheel, nor it offers resistence to movements. Such mode is enabled/disabled by clicking at the wheel (on this wheel, the middle button is a separate button). Add support for it. PS.: this patch series come after a patch series I sent during the weekend, with converts the input documentation to ReST format: [PATCH 00/33] Convert input documentation to ReST https://www.spinics.net/lists/linux-input/msg50659.html Both patch series can be seen at: https://git.linuxtv.org/mchehab/experimental.git/log/?h=input-docs And the documentation, formatted in HTML, at: https://www.infradead.org/~mchehab/kernel_docs/input/ Mauro Carvalho Chehab (4): input: add an EV_REL event for high-res vertical wheel input: add a EV_SW event for ratchet switch hid-logitech-hidpp: add support for high res wheel hid-logitech-hidpp: add support for ratchet switch Documentation/input/event-codes.rst| 32 - drivers/hid/hid-logitech-hidpp.c | 218 + include/linux/mod_devicetable.h| 2 +- include/uapi/linux/input-event-codes.h | 5 +- 4 files changed, 252 insertions(+), 5 deletions(-) -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] perf: xgene: Move PMU leaf functions into function pointer structure
This patch moves PMU leaf functions into a function pointer structure.
It helps code maintain and expasion easier.
Signed-off-by: Hoan Tran
---
drivers/perf/xgene_pmu.c | 85 +---
1 file changed, 66 insertions(+), 19 deletions(-)
diff --git a/drivers/perf/xgene_pmu.c b/drivers/perf/xgene_pmu.c
index 5ffd580..f34fc78 100644
--- a/drivers/perf/xgene_pmu.c
+++ b/drivers/perf/xgene_pmu.c
@@ -96,6 +96,23 @@ struct xgene_pmu_dev {
struct perf_event *pmu_counter_event[PMU_MAX_COUNTERS];
};
+struct xgene_pmu_ops {
+ void (*mask_int)(struct xgene_pmu *pmu);
+ void (*unmask_int)(struct xgene_pmu *pmu);
+ u64 (*read_counter)(struct xgene_pmu_dev *pmu, int idx);
+ void (*write_counter)(struct xgene_pmu_dev *pmu, int idx, u64 val);
+ void (*write_evttype)(struct xgene_pmu_dev *pmu_dev, int idx, u32 val);
+ void (*write_agentmsk)(struct xgene_pmu_dev *pmu_dev, u32 val);
+ void (*write_agent1msk)(struct xgene_pmu_dev *pmu_dev, u32 val);
+ void (*enable_counter)(struct xgene_pmu_dev *pmu_dev, int idx);
+ void (*disable_counter)(struct xgene_pmu_dev *pmu_dev, int idx);
+ void (*enable_counter_int)(struct xgene_pmu_dev *pmu_dev, int idx);
+ void (*disable_counter_int)(struct xgene_pmu_dev *pmu_dev, int idx);
+ void (*reset_counters)(struct xgene_pmu_dev *pmu_dev);
+ void (*start_counters)(struct xgene_pmu_dev *pmu_dev);
+ void (*stop_counters)(struct xgene_pmu_dev *pmu_dev);
+};
+
struct xgene_pmu {
struct device *dev;
int version;
@@ -104,6 +121,7 @@ struct xgene_pmu {
u32 mc_active_mask;
cpumask_t cpu;
raw_spinlock_t lock;
+ const struct xgene_pmu_ops *ops;
struct list_head l3cpmus;
struct list_head iobpmus;
struct list_head mcbpmus;
@@ -392,13 +410,14 @@ static inline void xgene_pmu_unmask_int(struct xgene_pmu
*xgene_pmu)
writel(PCPPMU_INTCLRMASK, xgene_pmu->pcppmu_csr + PCPPMU_INTMASK_REG);
}
-static inline u32 xgene_pmu_read_counter(struct xgene_pmu_dev *pmu_dev, int
idx)
+static inline u64 xgene_pmu_read_counter32(struct xgene_pmu_dev *pmu_dev,
+ int idx)
{
- return readl(pmu_dev->inf->csr + PMU_PMEVCNTR0 + (4 * idx));
+ return (u64)readl(pmu_dev->inf->csr + PMU_PMEVCNTR0 + (4 * idx));
}
static inline void
-xgene_pmu_write_counter(struct xgene_pmu_dev *pmu_dev, int idx, u32 val)
+xgene_pmu_write_counter32(struct xgene_pmu_dev *pmu_dev, int idx, u64 val)
{
writel(val, pmu_dev->inf->csr + PMU_PMEVCNTR0 + (4 * idx));
}
@@ -491,20 +510,22 @@ static inline void xgene_pmu_stop_counters(struct
xgene_pmu_dev *pmu_dev)
static void xgene_perf_pmu_enable(struct pmu *pmu)
{
struct xgene_pmu_dev *pmu_dev = to_pmu_dev(pmu);
+ struct xgene_pmu *xgene_pmu = pmu_dev->parent;
int enabled = bitmap_weight(pmu_dev->cntr_assign_mask,
pmu_dev->max_counters);
if (!enabled)
return;
- xgene_pmu_start_counters(pmu_dev);
+ xgene_pmu->ops->start_counters(pmu_dev);
}
static void xgene_perf_pmu_disable(struct pmu *pmu)
{
struct xgene_pmu_dev *pmu_dev = to_pmu_dev(pmu);
+ struct xgene_pmu *xgene_pmu = pmu_dev->parent;
- xgene_pmu_stop_counters(pmu_dev);
+ xgene_pmu->ops->stop_counters(pmu_dev);
}
static int xgene_perf_event_init(struct perf_event *event)
@@ -572,27 +593,32 @@ static int xgene_perf_event_init(struct perf_event *event)
static void xgene_perf_enable_event(struct perf_event *event)
{
struct xgene_pmu_dev *pmu_dev = to_pmu_dev(event->pmu);
+ struct xgene_pmu *xgene_pmu = pmu_dev->parent;
- xgene_pmu_write_evttype(pmu_dev, GET_CNTR(event), GET_EVENTID(event));
- xgene_pmu_write_agentmsk(pmu_dev, ~((u32)GET_AGENTID(event)));
+ xgene_pmu->ops->write_evttype(pmu_dev, GET_CNTR(event),
+ GET_EVENTID(event));
+ xgene_pmu->ops->write_agentmsk(pmu_dev, ~((u32)GET_AGENTID(event)));
if (pmu_dev->inf->type == PMU_TYPE_IOB)
- xgene_pmu_write_agent1msk(pmu_dev, ~((u32)GET_AGENT1ID(event)));
+ xgene_pmu->ops->write_agent1msk(pmu_dev,
+ ~((u32)GET_AGENT1ID(event)));
- xgene_pmu_enable_counter(pmu_dev, GET_CNTR(event));
- xgene_pmu_enable_counter_int(pmu_dev, GET_CNTR(event));
+ xgene_pmu->ops->enable_counter(pmu_dev, GET_CNTR(event));
+ xgene_pmu->ops->enable_counter_int(pmu_dev, GET_CNTR(event));
}
static void xgene_perf_disable_event(struct perf_event *event)
{
struct xgene_pmu_dev *pmu_dev = to_pmu_dev(event->pmu);
+ struct xgene_pmu *xgene_pmu = pmu_dev->parent;
- xgene_pmu_disable_counter(pmu_dev, GET_CNTR(event));
- xgene_pmu_disable_counter_int(pmu_dev, GET_CNTR(event));
+ xgene_pmu->ops->disable_counter(pmu_dev,
[PATCH v2 1/3] perf: xgene: Parse PMU subnode from the match table
This patch parses PMU Subnode from a match table.
Signed-off-by: Hoan Tran
---
drivers/perf/xgene_pmu.c | 40 ++--
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/drivers/perf/xgene_pmu.c b/drivers/perf/xgene_pmu.c
index 35b5289..5ffd580 100644
--- a/drivers/perf/xgene_pmu.c
+++ b/drivers/perf/xgene_pmu.c
@@ -1047,9 +1047,35 @@ xgene_pmu_dev_ctx *acpi_get_pmu_hw_inf(struct xgene_pmu
*xgene_pmu,
return NULL;
}
+static const struct acpi_device_id xgene_pmu_acpi_type_match[] = {
+ {"APMC0D5D", PMU_TYPE_L3C},
+ {"APMC0D5E", PMU_TYPE_IOB},
+ {"APMC0D5F", PMU_TYPE_MCB},
+ {"APMC0D60", PMU_TYPE_MC},
+ {},
+};
+
+static const struct acpi_device_id *xgene_pmu_acpi_match_type(
+ const struct acpi_device_id *ids,
+ struct acpi_device *adev)
+{
+ const struct acpi_device_id *match_id = NULL;
+ const struct acpi_device_id *id;
+
+ for (id = ids; id->id[0] || id->cls; id++) {
+ if (!acpi_match_device_ids(adev, id))
+ match_id = id;
+ else if (match_id)
+ break;
+ }
+
+ return match_id;
+}
+
static acpi_status acpi_pmu_dev_add(acpi_handle handle, u32 level,
void *data, void **return_value)
{
+ const struct acpi_device_id *acpi_id;
struct xgene_pmu *xgene_pmu = data;
struct xgene_pmu_dev_ctx *ctx;
struct acpi_device *adev;
@@ -1059,17 +1085,11 @@ static acpi_status acpi_pmu_dev_add(acpi_handle handle,
u32 level,
if (acpi_bus_get_status(adev) || !adev->status.present)
return AE_OK;
- if (!strcmp(acpi_device_hid(adev), "APMC0D5D"))
- ctx = acpi_get_pmu_hw_inf(xgene_pmu, adev, PMU_TYPE_L3C);
- else if (!strcmp(acpi_device_hid(adev), "APMC0D5E"))
- ctx = acpi_get_pmu_hw_inf(xgene_pmu, adev, PMU_TYPE_IOB);
- else if (!strcmp(acpi_device_hid(adev), "APMC0D5F"))
- ctx = acpi_get_pmu_hw_inf(xgene_pmu, adev, PMU_TYPE_MCB);
- else if (!strcmp(acpi_device_hid(adev), "APMC0D60"))
- ctx = acpi_get_pmu_hw_inf(xgene_pmu, adev, PMU_TYPE_MC);
- else
- ctx = NULL;
+ acpi_id = xgene_pmu_acpi_match_type(xgene_pmu_acpi_type_match, adev);
+ if (!acpi_id)
+ return AE_OK;
+ ctx = acpi_get_pmu_hw_inf(xgene_pmu, adev, (u32)acpi_id->driver_data);
if (!ctx)
return AE_OK;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] perf: xgene: Add support for SoC PMU version 3
This patch set adds support for SoC-wide (AKA uncore) Performance Monitoring Unit version 3. It can support up to - 2 IOB PMU instances - 8 L3C PMU instances - 2 MCB PMU instances - 8 MCU PMU instances v2: * Split into separate patches * Use the function pointers for the PMU leaf functions * Parse PMU subnode by the match table * Dont allow user change agent id by config1 for SoC PMU v3 Hoan Tran (3): perf: xgene: Parse PMU subnode from the match table perf: xgene: Move PMU leaf functions into function pointer structure perf: xgene: Add support for SoC PMU version 3 drivers/perf/xgene_pmu.c | 695 +-- 1 file changed, 619 insertions(+), 76 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] perf: xgene: Add support for SoC PMU version 3
This patch adds support for SoC-wide (AKA uncore) Performance Monitoring
Unit version 3.
It can support up to
- 2 IOB PMU instances
- 8 L3C PMU instances
- 2 MCB PMU instances
- 8 MCU PMU instances
Signed-off-by: Hoan Tran
---
drivers/perf/xgene_pmu.c | 572 +++
1 file changed, 524 insertions(+), 48 deletions(-)
diff --git a/drivers/perf/xgene_pmu.c b/drivers/perf/xgene_pmu.c
index f34fc78..a72814d 100644
--- a/drivers/perf/xgene_pmu.c
+++ b/drivers/perf/xgene_pmu.c
@@ -37,6 +37,8 @@
#define CSW_CSWCR 0x
#define CSW_CSWCR_DUALMCB_MASK BIT(0)
+#define CSW_CSWCR_MCB0_ROUTING(x) (((x) & 0x0C) >> 2)
+#define CSW_CSWCR_MCB1_ROUTING(x) (((x) & 0x30) >> 4)
#define MCBADDRMR 0x
#define MCBADDRMR_DUALMCU_MODE_MASKBIT(2)
@@ -50,8 +52,17 @@
#define PCPPMU_INT_L3CBIT(2)
#define PCPPMU_INT_IOBBIT(3)
+#define PCPPMU_V3_INTMASK 0x00FF33FF
+#define PCPPMU_V3_INTENMASK 0x
+#define PCPPMU_V3_INTCLRMASK 0xFF00CC00
+#define PCPPMU_V3_INT_MCU 0x00FF
+#define PCPPMU_V3_INT_MCB 0x0300
+#define PCPPMU_V3_INT_L3C 0x00FF
+#define PCPPMU_V3_INT_IOB 0x3000
+
#define PMU_MAX_COUNTERS 4
-#define PMU_CNT_MAX_PERIOD 0x1ULL
+#define PMU_CNT_MAX_PERIOD 0xULL
+#define PMU_V3_CNT_MAX_PERIOD 0xULL
#define PMU_OVERFLOW_MASK 0xF
#define PMU_PMCR_E BIT(0)
#define PMU_PMCR_P BIT(1)
@@ -73,6 +84,10 @@
#define PMU_PMOVSR 0xC80
#define PMU_PMCR 0xE04
+/* PMU registers for V3 */
+#define PMU_PMOVSCLR 0xC80
+#define PMU_PMOVSSET 0xCC0
+
#define to_pmu_dev(p) container_of(p, struct xgene_pmu_dev, pmu)
#define GET_CNTR(ev) (ev->hw.idx)
#define GET_EVENTID(ev) (ev->hw.config & 0xFFULL)
@@ -119,6 +134,7 @@ struct xgene_pmu {
void __iomem *pcppmu_csr;
u32 mcb_active_mask;
u32 mc_active_mask;
+ u32 l3c_active_mask;
cpumask_t cpu;
raw_spinlock_t lock;
const struct xgene_pmu_ops *ops;
@@ -143,11 +159,13 @@ struct xgene_pmu_data {
enum xgene_pmu_version {
PCP_PMU_V1 = 1,
PCP_PMU_V2,
+ PCP_PMU_V3,
};
enum xgene_pmu_dev_type {
PMU_TYPE_L3C = 0,
PMU_TYPE_IOB,
+ PMU_TYPE_IOB_SLOW,
PMU_TYPE_MCB,
PMU_TYPE_MC,
};
@@ -213,6 +231,56 @@ static ssize_t xgene_pmu_format_show(struct device *dev,
.attrs = mc_pmu_format_attrs,
};
+static struct attribute *l3c_pmu_v3_format_attrs[] = {
+ XGENE_PMU_FORMAT_ATTR(l3c_eventid, "config:0-39"),
+ NULL,
+};
+
+static struct attribute *iob_pmu_v3_format_attrs[] = {
+ XGENE_PMU_FORMAT_ATTR(iob_eventid, "config:0-47"),
+ NULL,
+};
+
+static struct attribute *iob_slow_pmu_v3_format_attrs[] = {
+ XGENE_PMU_FORMAT_ATTR(iob_slow_eventid, "config:0-16"),
+ NULL,
+};
+
+static struct attribute *mcb_pmu_v3_format_attrs[] = {
+ XGENE_PMU_FORMAT_ATTR(mcb_eventid, "config:0-35"),
+ NULL,
+};
+
+static struct attribute *mc_pmu_v3_format_attrs[] = {
+ XGENE_PMU_FORMAT_ATTR(mc_eventid, "config:0-44"),
+ NULL,
+};
+
+static const struct attribute_group l3c_pmu_v3_format_attr_group = {
+ .name = "format",
+ .attrs = l3c_pmu_v3_format_attrs,
+};
+
+static const struct attribute_group iob_pmu_v3_format_attr_group = {
+ .name = "format",
+ .attrs = iob_pmu_v3_format_attrs,
+};
+
+static const struct attribute_group iob_slow_pmu_v3_format_attr_group = {
+ .name = "format",
+ .attrs = iob_slow_pmu_v3_format_attrs,
+};
+
+static const struct attribute_group mcb_pmu_v3_format_attr_group = {
+ .name = "format",
+ .attrs = mcb_pmu_v3_format_attrs,
+};
+
+static const struct attribute_group mc_pmu_v3_format_attr_group = {
+ .name = "format",
+ .attrs = mc_pmu_v3_format_attrs,
+};
+
/*
* sysfs event attributes
*/
@@ -329,6 +397,219 @@ static ssize_t xgene_pmu_event_show(struct device *dev,
.attrs = mc_pmu_events_attrs,
};
+static struct attribute *l3c_pmu_v3_events_attrs[] = {
+ XGENE_PMU_EVENT_ATTR(cycle-count, 0x00),
+ XGENE_PMU_EVENT_ATTR(read-hit, 0x01),
+ XGENE_PMU_EVENT_ATTR(read-miss, 0x02),
+ XGENE_PMU_EVENT_ATTR(index-flush-eviction, 0x03),
+ XGENE_PMU_EVENT_ATTR(write-caused-replacement, 0x04),
+ XGENE_PMU_EVENT_ATTR(write-not-caused-replacement, 0x05),
+ XGENE_PMU_EVENT_ATTR(clean-eviction,0x06),
+ XGENE_PMU_EVENT_ATTR(dirty-eviction,0x07),
+ XGENE_PMU_EVENT_ATTR(reads, 0x08),
+ XGENE_PMU_EVENT_ATTR(writes,0x09),
+ XGENE_PMU_EVENT_ATTR(requests,
[PATCH v6 3/6] documentation: media: Add documentation for new RGB and YUV bus formats
Add documentation for added Bus Formats to describe RGB and YUV formats used
as input to the Synopsys DesignWare HDMI TX Controller.
Acked-by: Hans Verkuil
Reviewed-by: Archit Taneja
Acked-by: Mauro Carvalho Chehab
Signed-off-by: Neil Armstrong
---
Documentation/media/uapi/v4l/subdev-formats.rst | 960 +++-
1 file changed, 959 insertions(+), 1 deletion(-)
diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst
b/Documentation/media/uapi/v4l/subdev-formats.rst
index d6152c9..4032d97 100644
--- a/Documentation/media/uapi/v4l/subdev-formats.rst
+++ b/Documentation/media/uapi/v4l/subdev-formats.rst
@@ -1258,6 +1258,319 @@ The following tables list existing packed RGB formats.
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
+* .. _MEDIA-BUS-FMT-RGB101010-1X30:
+
+ - MEDIA_BUS_FMT_RGB101010_1X30
+ - 0x1018
+ -
+ - 0
+ - 0
+ - r\ :sub:`9`
+ - r\ :sub:`8`
+ - r\ :sub:`7`
+ - r\ :sub:`6`
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - g\ :sub:`9`
+ - g\ :sub:`8`
+ - g\ :sub:`7`
+ - g\ :sub:`6`
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - b\ :sub:`9`
+ - b\ :sub:`8`
+ - b\ :sub:`7`
+ - b\ :sub:`6`
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - b\ :sub:`3`
+ - b\ :sub:`2`
+ - b\ :sub:`1`
+ - b\ :sub:`0`
+
+.. raw:: latex
+
+\endgroup
+
+
+The following table list existing packed 36bit wide RGB formats.
+
+.. tabularcolumns::
|p{4.0cm}|p{0.7cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
+
+.. _v4l2-mbus-pixelcode-rgb-36:
+
+.. raw:: latex
+
+\begingroup
+\tiny
+\setlength{\tabcolsep}{2pt}
+
+.. flat-table:: 36bit RGB formats
+:header-rows: 2
+:stub-columns: 0
+:widths: 36 7 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2
+
+* - Identifier
+ - Code
+ -
+ - :cspan:`35` Data organization
+* -
+ -
+ - Bit
+ - 35
+ - 34
+ - 33
+ - 32
+ - 31
+ - 30
+ - 29
+ - 28
+ - 27
+ - 26
+ - 25
+ - 24
+ - 23
+ - 22
+ - 21
+ - 20
+ - 19
+ - 18
+ - 17
+ - 16
+ - 15
+ - 14
+ - 13
+ - 12
+ - 11
+ - 10
+ - 9
+ - 8
+ - 7
+ - 6
+ - 5
+ - 4
+ - 3
+ - 2
+ - 1
+ - 0
+* .. _MEDIA-BUS-FMT-RGB121212-1X36:
+
+ - MEDIA_BUS_FMT_RGB121212_1X36
+ - 0x1019
+ -
+ - r\ :sub:`11`
+ - r\ :sub:`10`
+ - r\ :sub:`9`
+ - r\ :sub:`8`
+ - r\ :sub:`7`
+ - r\ :sub:`6`
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - g\ :sub:`11`
+ - g\ :sub:`10`
+ - g\ :sub:`9`
+ - g\ :sub:`8`
+ - g\ :sub:`7`
+ - g\ :sub:`6`
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - b\ :sub:`11`
+ - b\ :sub:`10`
+ - b\ :sub:`9`
+ - b\ :sub:`8`
+ - b\ :sub:`7`
+ - b\ :sub:`6`
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - b\ :sub:`3`
+ - b\ :sub:`2`
+ - b\ :sub:`1`
+ - b\ :sub:`0`
+
+.. raw:: latex
+
+\endgroup
+
+
+The following table list existing packed 48bit wide RGB formats.
+
+.. tabularcolumns::
|p{4.0cm}|p{0.7cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
+
+.. _v4l2-mbus-pixelcode-rgb-48:
+
+.. raw:: latex
+
+\begingroup
+\tiny
+\setlength{\tabcolsep}{2pt}
+
+.. flat-table:: 48bit RGB formats
+:header-rows: 3
+:stub-columns: 0
+:widths: 36 7 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2
+
+* - Identifier
+ - Code
+ -
+ - :cspan:`31` Data organization
+* -
+ -
+ - Bit
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ - 47
+ - 46
+ - 45
+ - 44
+ - 43
+ - 42
+ - 41
+ - 40
+ - 39
+ - 38
+ - 37
+ - 36
+ - 35
+ - 34
+ - 33
+ - 32
+* -
+ -
+ -
+ -
[PATCH v6 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings
Some display pipelines can only provide non-RBG input pixels to the HDMI TX
Controller, this patch takes the pixel format from the plat_data if provided.
Reviewed-by: Jose Abreu
Reviewed-by: Archit Taneja
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 326 +-
include/drm/bridge/dw_hdmi.h | 63 ++
2 files changed, 294 insertions(+), 95 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ff1fae3..16d5fff3 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -30,18 +30,15 @@
#include
#include
+#include
+#include
+
#include "dw-hdmi.h"
#include "dw-hdmi-audio.h"
#define DDC_SEGMENT_ADDR 0x30
#define HDMI_EDID_LEN 512
-#define RGB0
-#define YCBCR444 1
-#define YCBCR422_16BITS2
-#define YCBCR422_8BITS 3
-#define XVYCC444 4
-
enum hdmi_datamap {
RGB444_8B = 0x01,
RGB444_10B = 0x03,
@@ -95,10 +92,10 @@ struct hdmi_vmode {
};
struct hdmi_data_info {
- unsigned int enc_in_format;
- unsigned int enc_out_format;
- unsigned int enc_color_depth;
- unsigned int colorimetry;
+ unsigned int enc_in_bus_format;
+ unsigned int enc_out_bus_format;
+ unsigned int enc_in_encoding;
+ unsigned int enc_out_encoding;
unsigned int pix_repet_factor;
unsigned int hdcp_enable;
struct hdmi_vmode video_mode;
@@ -567,6 +564,92 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
}
EXPORT_SYMBOL_GPL(dw_hdmi_audio_disable);
+static bool hdmi_bus_fmt_is_rgb(unsigned int bus_format)
+{
+ switch (bus_format) {
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ case MEDIA_BUS_FMT_RGB101010_1X30:
+ case MEDIA_BUS_FMT_RGB121212_1X36:
+ case MEDIA_BUS_FMT_RGB161616_1X48:
+ return true;
+
+ default:
+ return false;
+ }
+}
+
+static bool hdmi_bus_fmt_is_yuv444(unsigned int bus_format)
+{
+ switch (bus_format) {
+ case MEDIA_BUS_FMT_YUV8_1X24:
+ case MEDIA_BUS_FMT_YUV10_1X30:
+ case MEDIA_BUS_FMT_YUV12_1X36:
+ case MEDIA_BUS_FMT_YUV16_1X48:
+ return true;
+
+ default:
+ return false;
+ }
+}
+
+static bool hdmi_bus_fmt_is_yuv422(unsigned int bus_format)
+{
+ switch (bus_format) {
+ case MEDIA_BUS_FMT_UYVY8_1X16:
+ case MEDIA_BUS_FMT_UYVY10_1X20:
+ case MEDIA_BUS_FMT_UYVY12_1X24:
+ return true;
+
+ default:
+ return false;
+ }
+}
+
+static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
+{
+ switch (bus_format) {
+ case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
+ case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
+ case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
+ case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
+ return true;
+
+ default:
+ return false;
+ }
+}
+
+static int hdmi_bus_fmt_color_depth(unsigned int bus_format)
+{
+ switch (bus_format) {
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ case MEDIA_BUS_FMT_YUV8_1X24:
+ case MEDIA_BUS_FMT_UYVY8_1X16:
+ case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
+ return 8;
+
+ case MEDIA_BUS_FMT_RGB101010_1X30:
+ case MEDIA_BUS_FMT_YUV10_1X30:
+ case MEDIA_BUS_FMT_UYVY10_1X20:
+ case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
+ return 10;
+
+ case MEDIA_BUS_FMT_RGB121212_1X36:
+ case MEDIA_BUS_FMT_YUV12_1X36:
+ case MEDIA_BUS_FMT_UYVY12_1X24:
+ case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
+ return 12;
+
+ case MEDIA_BUS_FMT_RGB161616_1X48:
+ case MEDIA_BUS_FMT_YUV16_1X48:
+ case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
+ return 16;
+
+ default:
+ return 0;
+ }
+}
+
/*
* this submodule is responsible for the video data synchronization.
* for example, for RGB 4:4:4 input, the data map is defined as
@@ -579,37 +662,49 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
int color_format = 0;
u8 val;
- if (hdmi->hdmi_data.enc_in_format == RGB) {
- if (hdmi->hdmi_data.enc_color_depth == 8)
- color_format = 0x01;
- else if (hdmi->hdmi_data.enc_color_depth == 10)
- color_format = 0x03;
- else if (hdmi->hdmi_data.enc_color_depth == 12)
- color_format = 0x05;
- else if (hdmi->hdmi_data.enc_color_depth == 16)
- color_format = 0x07;
- else
- return;
- } else if (hdmi->hdmi_data.enc_in_format == YCBCR444) {
- if (hdmi->hdmi_data.enc_color_depth == 8)
- color_format = 0x09;
- else if (hdmi->hdmi_data.enc_color_depth == 10)
-
[PATCH v6 5/6] drm: bridge: dw-hdmi: Add Documentation on supported input formats
This patch adds a new DRM documentation entry and links to the input format table added in the dw_hdmi header. Reviewed-by: Archit Taneja Signed-off-by: Neil Armstrong --- Documentation/gpu/bridge/dw-hdmi.rst | 15 +++ Documentation/gpu/index.rst | 1 + 2 files changed, 16 insertions(+) create mode 100644 Documentation/gpu/bridge/dw-hdmi.rst diff --git a/Documentation/gpu/bridge/dw-hdmi.rst b/Documentation/gpu/bridge/dw-hdmi.rst new file mode 100644 index 000..486faad --- /dev/null +++ b/Documentation/gpu/bridge/dw-hdmi.rst @@ -0,0 +1,15 @@ +=== + drm/bridge/dw-hdmi Synopsys DesignWare HDMI Controller +=== + +Synopsys DesignWare HDMI Controller +=== + +This section covers everything related to the Synopsys DesignWare HDMI +Controller implemented as a DRM bridge. + +Supported Input Formats and Encodings +- + +.. kernel-doc:: include/drm/bridge/dw_hdmi.h + :doc: Supported input formats and encodings diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index e998ee0..d81c6ff 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -15,6 +15,7 @@ Linux GPU Driver Developer's Guide vc4 vga-switcheroo vgaarbiter + bridge/dw-hdmi todo .. only:: subproject and html -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 6/6] drm: bridge: dw-hdmi: Move HPD handling to PHY operations
The HDMI TX controller support HPD and RXSENSE signaling from the PHY
via it's STAT0 PHY interface, but some vendor PHYs can manage these
signals independently from the controller, thus these STAT0 handling
should be moved to PHY specific operations and become optional.
The existing STAT0 HPD and RXSENSE handling code is refactored into
a supplementaty set of default PHY operations that are used automatically
when the platform glue doesn't provide its own operations.
Reviewed-by: Jose Abreu
Reviewed-by: Archit Taneja
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 135 ++
include/drm/bridge/dw_hdmi.h | 5 ++
2 files changed, 86 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 16d5fff3..84cc949 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1229,10 +1229,46 @@ static enum drm_connector_status
dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
connector_status_connected : connector_status_disconnected;
}
+static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+ bool force, bool disabled, bool rxsense)
+{
+ u8 old_mask = hdmi->phy_mask;
+
+ if (force || disabled || !rxsense)
+ hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
+ else
+ hdmi->phy_mask &= ~HDMI_PHY_RX_SENSE;
+
+ if (old_mask != hdmi->phy_mask)
+ hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
+}
+
+static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
+{
+ /*
+* Configure the PHY RX SENSE and HPD interrupts polarities and clear
+* any pending interrupt.
+*/
+ hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
+ hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
+ HDMI_IH_PHY_STAT0);
+
+ /* Enable cable hot plug irq. */
+ hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
+
+ /* Clear and unmute interrupts. */
+ hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
+ HDMI_IH_PHY_STAT0);
+ hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
+ HDMI_IH_MUTE_PHY_STAT0);
+}
+
static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
.init = dw_hdmi_phy_init,
.disable = dw_hdmi_phy_disable,
.read_hpd = dw_hdmi_phy_read_hpd,
+ .update_hpd = dw_hdmi_phy_update_hpd,
+ .setup_hpd = dw_hdmi_phy_setup_hpd,
};
/*
-
@@ -1808,35 +1844,10 @@ static void dw_hdmi_update_power(struct dw_hdmi *hdmi)
*/
static void dw_hdmi_update_phy_mask(struct dw_hdmi *hdmi)
{
- u8 old_mask = hdmi->phy_mask;
-
- if (hdmi->force || hdmi->disabled || !hdmi->rxsense)
- hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
- else
- hdmi->phy_mask &= ~HDMI_PHY_RX_SENSE;
-
- if (old_mask != hdmi->phy_mask)
- hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
-}
-
-static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi)
-{
- /*
-* Configure the PHY RX SENSE and HPD interrupts polarities and clear
-* any pending interrupt.
-*/
- hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
- hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
- HDMI_IH_PHY_STAT0);
-
- /* Enable cable hot plug irq. */
- hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
-
- /* Clear and unmute interrupts. */
- hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
- HDMI_IH_PHY_STAT0);
- hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
- HDMI_IH_MUTE_PHY_STAT0);
+ if (hdmi->phy.ops->update_hpd)
+ hdmi->phy.ops->update_hpd(hdmi, hdmi->phy.data,
+ hdmi->force, hdmi->disabled,
+ hdmi->rxsense);
}
static enum drm_connector_status
@@ -2028,6 +2039,41 @@ static irqreturn_t dw_hdmi_hardirq(int irq, void *dev_id)
return ret;
}
+void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
+{
+ mutex_lock(&hdmi->mutex);
+
+ if (!hdmi->force) {
+ /*
+* If the RX sense status indicates we're disconnected,
+* clear the software rxsense status.
+*/
+ if (!rx_sense)
+ hdmi->rxsense = false;
+
+ /*
+* Only set the software rxsense status when both
+* rxsense and hpd indicates we're connected.
+* This avoids what seems to
[PATCH v6 0/6] drm: bridge: dw-hdmi: Add support for Custom PHYs
The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller in combination with a very custom PHY. Thanks to Laurent Pinchart's changes, the HW report the following : Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy) The following differs from common PHY integration as managed in the current driver : - Amlogic PHY is not configured through the internal I2C link - Amlogic PHY do not use the ENTMDS, SVSRET, PDDQ, ... signals from the controller - Amlogic PHY do not export HPD ands RxSense signals to the controller And finally, concerning the controller integration : - the Controller registers are not flat memory-mapped, and uses an addr+read/write register pair to write all registers. - Inputs only YUV444 pixel data Most of these uses case are implemented in Laurent Pinchart v5.1 patchset merged in drm-misc-next branch. This is why the following patchset implements : - Configure the Input format from the plat_data - Add PHY callback to handle HPD and RxSense out of the dw-hdmi driver To implement the input format handling, the Synopsys HDMIT TX Controller input V4L bus formats are used and missing formats + documentation are added. This patchset makes the Amlogic GX SoCs HDMI output successfully work, and is also tested on the RK3288 ACT8846 EVB Board. Changes since v5.1 at [7] : - Rework of the 48bit tables in V4L bus formats documentation - Add Archit reviewed-by's Changes since v5 at [6] : - Small addition in V4L YUV bus formats documentation Changes since v4 at [5] : - Rebased on drm-misc-next at bd283d2f66c2 - Fix 4:2:0 bus formats naming - Renamed function fd_registered to i2c_init in dw-hdmi.c Changes since v3 at [4] : - Fix 4:2:0 bus formats naming - Add separate 36bit and 48bit tables for bus formats documentation - Added 4:2:0 bus config in hdmi_video_sample - Moved dw_hdmi documentation in a "bridge" subdir - Rebase on drm-misc-next at 62c58af32c93 Changes since v2 at [3] : - Rebase on laurent patch "Extract PHY interrupt setup to a function" - Reduce phy operations - Switch the V4L bus formats and encodings instead of custom enum Changes since v1 at [2] : - Drop patches submitted by laurent Changes since RFC at [1] : - Regmap fixup for 4bytes register access, tested on RK3288 SoC - Move phy callbacks to phy_ops and move Synopsys PHY calls into default ops - Move HDMI link data into shared header - Move Pixel Encoding enum to shared header [1] http://lkml.kernel.org/r/1484656294-6140-1-git-send-email-narmstr...@baylibre.com [2] http://lkml.kernel.org/r/1485774318-21916-1-git-send-email-narmstr...@baylibre.com [3] http://lkml.kernel.org/r/1488468572-31971-1-git-send-email-narmstr...@baylibre.com [4] http://lkml.kernel.org/r/1488904944-14285-1-git-send-email-narmstr...@baylibre.com [5] http://lkml.kernel.org/r/1490109161-20529-1-git-send-email-narmstr...@baylibre.com [6] http://lkml.kernel.org/r/1490864675-17336-1-git-send-email-narmstr...@baylibre.com [7] http://lkml.kernel.org/r/1490970319-24981-1-git-send-email-narmstr...@baylibre.com Laurent Pinchart (1): drm: bridge: dw-hdmi: Extract PHY interrupt setup to a function Neil Armstrong (5): media: uapi: Add RGB and YUV bus formats for Synopsys HDMI TX Controller documentation: media: Add documentation for new RGB and YUV bus formats drm: bridge: dw-hdmi: Switch to V4L bus format and encodings drm: bridge: dw-hdmi: Add Documentation on supported input formats drm: bridge: dw-hdmi: Move HPD handling to PHY operations Documentation/gpu/bridge/dw-hdmi.rst| 15 + Documentation/gpu/index.rst | 1 + Documentation/media/uapi/v4l/subdev-formats.rst | 960 +++- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 470 include/drm/bridge/dw_hdmi.h| 68 ++ include/uapi/linux/media-bus-format.h | 13 +- 6 files changed, 1368 insertions(+), 159 deletions(-) create mode 100644 Documentation/gpu/bridge/dw-hdmi.rst -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: stable-kernel-rules: fix stable-tag format
A patch documenting how to specify which kernels a particular fix should
be backported to (seemingly) inadvertently added a minus sign after the
kernel version. This particular stable-tag format had never been used
prior to this patch, and was neither present when the patch in question
was first submitted (it was added in v2 without any comment).
Drop the minus sign to avoid any confusion.
Fixes: fdc81b7910ad ("stable_kernel_rules: Add clause about specification of
kernel versions to patch.")
Signed-off-by: Johan Hovold
---
Documentation/process/stable-kernel-rules.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/process/stable-kernel-rules.rst
b/Documentation/process/stable-kernel-rules.rst
index 11ec2d93a5e0..61e9c78bd6d1 100644
--- a/Documentation/process/stable-kernel-rules.rst
+++ b/Documentation/process/stable-kernel-rules.rst
@@ -124,7 +124,7 @@ specified in the following format in the sign-off area:
.. code-block:: none
- Cc: # 3.3.x-
+ Cc: # 3.3.x
The tag has the meaning of:
--
2.12.2
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] tracing/kprobes: expose maxactive for kretprobe in kprobe_events
From: Alban Crequy
When a kretprobe is installed on a kernel function, there is a maximum
limit of how many calls in parallel it can catch (aka "maxactive"). A
kernel module could call register_kretprobe() and initialize maxactive
(see example in samples/kprobes/kretprobe_example.c).
But that is not exposed to userspace and it is currently not possible to
choose maxactive when writing to /sys/kernel/debug/tracing/kprobe_events
The default maxactive can be as low as 1 on single-core with a
non-preemptive kernel. This is too low and we need to increase it not
only for recursive functions, but for functions that sleep or resched.
This patch updates the format of the command that can be written to
kprobe_events so that maxactive can be optionally specified.
I need this for a bpf program attached to the kretprobe of
inet_csk_accept, which can sleep for a long time.
This patch includes a basic selftest:
> # ./ftracetest -v test.d/kprobe/
> === Ftrace unit tests ===
> [1] Kprobe dynamic event - adding and removing[PASS]
> [2] Kprobe dynamic event - busy event check [PASS]
> [3] Kprobe dynamic event with arguments [PASS]
> [4] Kprobes event arguments with types[PASS]
> [5] Kprobe dynamic event with function tracer [PASS]
> [6] Kretprobe dynamic event with arguments[PASS]
> [7] Kretprobe dynamic event with maxactive[PASS]
>
> # of passed: 7
> # of failed: 0
> # of unresolved: 0
> # of untested: 0
> # of unsupported: 0
> # of xfailed: 0
> # of undefined(test bug): 0
BugLink: https://github.com/iovisor/bcc/issues/1072
Signed-off-by: Alban Crequy
---
Changes since v2:
- Explain the default maxactive value in the documentation.
(Review from Steven Rostedt)
Changes since v1:
- Remove "(*)" from documentation. (Review from Masami Hiramatsu)
- Fix support for "r100" without the event name (Review from Masami Hiramatsu)
- Get rid of magic numbers within the code. (Review from Steven Rostedt)
Note that I didn't use KRETPROBE_MAXACTIVE_ALLOC since that patch is not
merged.
- Return -E2BIG when maxactive is too big.
- Add basic selftest
---
Documentation/trace/kprobetrace.txt| 5 ++-
kernel/trace/trace_kprobe.c| 39 ++
.../ftrace/test.d/kprobe/kretprobe_maxactive.tc| 39 ++
3 files changed, 76 insertions(+), 7 deletions(-)
create mode 100644
tools/testing/selftests/ftrace/test.d/kprobe/kretprobe_maxactive.tc
diff --git a/Documentation/trace/kprobetrace.txt
b/Documentation/trace/kprobetrace.txt
index 41ef9d8..25f3960 100644
--- a/Documentation/trace/kprobetrace.txt
+++ b/Documentation/trace/kprobetrace.txt
@@ -23,7 +23,7 @@ current_tracer. Instead of that, add probe points via
Synopsis of kprobe_events
-
p[:[GRP/]EVENT] [MOD:]SYM[+offs]|MEMADDR [FETCHARGS] : Set a probe
- r[:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS]: Set a return probe
+ r[MAXACTIVE][:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS] : Set a return probe
-:[GRP/]EVENT: Clear a probe
GRP : Group name. If omitted, use "kprobes" for it.
@@ -32,6 +32,9 @@ Synopsis of kprobe_events
MOD : Module name which has given SYM.
SYM[+offs]: Symbol+offset where the probe is inserted.
MEMADDR : Address where the probe is inserted.
+ MAXACTIVE : Maximum number of instances of the specified function that
+ can be probed simultaneously, or 0 for the default value
+ as defined in Documentation/kprobes.txt section 1.3.1.
FETCHARGS : Arguments. Each probe can have up to 128 args.
%REG : Fetch register REG
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index c5089c7..ae81f3c 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -25,6 +25,7 @@
#include "trace_probe.h"
#define KPROBE_EVENT_SYSTEM "kprobes"
+#define KRETPROBE_MAXACTIVE_MAX 4096
/**
* Kprobe event core functions
@@ -282,6 +283,7 @@ static struct trace_kprobe *alloc_trace_kprobe(const char
*group,
void *addr,
const char *symbol,
unsigned long offs,
+int maxactive,
int nargs, bool is_return)
{
struct trace_kprobe *tk;
@@ -309,6 +311,8 @@ static struct trace_kprobe *alloc_trace_kprobe(const char
*group,
else
tk->rp.kp.pre_handler = kprobe_dispatcher;
+ tk->rp.maxactive = maxactive;
+
if (!event || !is_good_name(event)) {
ret = -EINVAL;
goto error;
@@ -598,8 +602,10 @@ static int create_trace_kprobe(int argc, char **argv)
{
/*
* Argument syntax:
-* - Add kprobe: p[:[GRP/]EVENT] [MOD:]KSYM[+OFFS]|KADDR [FETCHARGS]
-
Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests
On 03/29/2017 02:11 PM, Radim Krčmář wrote: 2017-03-28 13:35-0700, Jim Mattson: On Tue, Mar 28, 2017 at 7:28 AM, Radim Krčmář wrote: 2017-03-27 15:34+0200, Alexander Graf: On 15/03/2017 22:22, Michael S. Tsirkin wrote: Guests running Mac OS 5, 6, and 7 (Leopard through Lion) have a problem: unless explicitly provided with kernel command line argument "idlehalt=0" they'd implicitly assume MONITOR and MWAIT availability, without checking CPUID. We currently emulate that as a NOP but on VMX we can do better: let guest stop the CPU until timer, IPI or memory change. CPU will be busy but that isn't any worse than a NOP emulation. Note that mwait within guests is not the same as on real hardware because halt causes an exit while mwait doesn't. For this reason it might not be a good idea to use the regular MWAIT flag in CPUID to signal this capability. Add a flag in the hypervisor leaf instead. So imagine we had proper MWAIT emulation capabilities based on page faults. In that case, we could do something as fancy as Treat MWAIT as pass-through by default Have a per-vcpu monitor timer 10 times a second in the background that checks which instruction we're in If we're in mwait for the last - say - 1 second, switch to emulated MWAIT, if $IP was in non-mwait within that time, reset counter. Or we could reuse external interrupts for sampling. Exits trigerred by them would check for current instruction (probably would be best to limit just to timer tick) and a sufficient ratio (> 0?) of other exits would imply that MWAIT is not used. Or instead maybe just reuse the adapter hlt logic? Emulated MWAIT is very similar to emulated HLT, so reusing the logic makes sense. We would just add new wakeup methods. Either way, with that we should be able to get super low latency IPIs running while still maintaining some sanity on systems which don't have dedicated CPUs for workloads. And we wouldn't need guest modifications, which is a great plus. So older guests (and Windows?) could benefit from mwait as well. There is no need guest modifications -- it could be exposed as standard MWAIT feature to the guest, with responsibilities for guest/host-impact on the user. I think that the page-fault based MWAIT would require paravirt if it should be enabled by default, because of performance concerns: Enabling write protection on a page needs a VM exit on all other VCPUs when beginning monitoring (to reload page permissions and prevent missed writes). We'd want to keep trapping writes to the page all the time because toggling is slow, but this could regress performance for an OS that has other data accessed by other VCPUs in that page. No current interface can tell the guest that it should reserve the whole page instead of what CPUID[5] says and that writes to the monitored page are not "cheap", but can trigger a VM exit ... CPUID.05H:EBX is supposed to address the false sharing issue. IIRC, VMware Fusion reports 64 in CPUID.05H:EAX and 4096 in CPUID.05H:EBX when running Mac OS X guests. Per Intel's SDM volume 3, section 8.10.5, "To avoid false wake-ups; use the largest monitor line size to pad the data structure used to monitor writes. Software must make sure that beyond the data structure, no unrelated data variable exists in the triggering area for MWAIT. A pad may be needed to avoid this situation." Unfortunately, most operating systems do not follow this advice. Right, EBX provides what we need to expose that the whole page is monitored, thanks! So coming back to the original patch, is there anything that should keep us from exposing MWAIT straight into the guest at all times? Alex -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5.1 0/6] drm: bridge: dw-hdmi: Add support for Custom PHYs
Hi, On 03/31/2017 07:55 PM, Neil Armstrong wrote: The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller in combination with a very custom PHY. Thanks to Laurent Pinchart's changes, the HW report the following : Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy) The following differs from common PHY integration as managed in the current driver : - Amlogic PHY is not configured through the internal I2C link - Amlogic PHY do not use the ENTMDS, SVSRET, PDDQ, ... signals from the controller - Amlogic PHY do not export HPD ands RxSense signals to the controller And finally, concerning the controller integration : - the Controller registers are not flat memory-mapped, and uses an addr+read/write register pair to write all registers. - Inputs only YUV444 pixel data Most of these uses case are implemented in Laurent Pinchart v5.1 patchset merged in drm-misc-next branch. This is why the following patchset implements : - Configure the Input format from the plat_data - Add PHY callback to handle HPD and RxSense out of the dw-hdmi driver To implement the input format handling, the Synopsys HDMIT TX Controller input V4L bus formats are used and missing formats + documentation are added. This patchset makes the Amlogic GX SoCs HDMI output successfully work, and is also tested on the RK3288 ACT8846 EVB Board. Please feel free to add my Reviewed-by for all the patches. Did we get an Ack from the v4l maintainers to take the media changes via the drm-misc branch? If so, I guess we could go ahead and push the series to drm-misc-next. Thanks, Archit Changes since v5 at [6] : - Small addition in V4L YUV bus formats documentation Changes since v4 at [5] : - Rebased on drm-misc-next at bd283d2f66c2 - Fix 4:2:0 bus formats naming - Renamed function fd_registered to i2c_init in dw-hdmi.c Changes since v3 at [4] : - Fix 4:2:0 bus formats naming - Add separate 36bit and 48bit tables for bus formats documentation - Added 4:2:0 bus config in hdmi_video_sample - Moved dw_hdmi documentation in a "bridge" subdir - Rebase on drm-misc-next at 62c58af32c93 Changes since v2 at [3] : - Rebase on laurent patch "Extract PHY interrupt setup to a function" - Reduce phy operations - Switch the V4L bus formats and encodings instead of custom enum Changes since v1 at [2] : - Drop patches submitted by laurent Changes since RFC at [1] : - Regmap fixup for 4bytes register access, tested on RK3288 SoC - Move phy callbacks to phy_ops and move Synopsys PHY calls into default ops - Move HDMI link data into shared header - Move Pixel Encoding enum to shared header [1] http://lkml.kernel.org/r/1484656294-6140-1-git-send-email-narmstr...@baylibre.com [2] http://lkml.kernel.org/r/1485774318-21916-1-git-send-email-narmstr...@baylibre.com [3] http://lkml.kernel.org/r/1488468572-31971-1-git-send-email-narmstr...@baylibre.com [4] http://lkml.kernel.org/r/1488904944-14285-1-git-send-email-narmstr...@baylibre.com [5] http://lkml.kernel.org/r/1490109161-20529-1-git-send-email-narmstr...@baylibre.com [6] http://lkml.kernel.org/r/1490864675-17336-1-git-send-email-narmstr...@baylibre.com Laurent Pinchart (1): drm: bridge: dw-hdmi: Extract PHY interrupt setup to a function Neil Armstrong (5): media: uapi: Add RGB and YUV bus formats for Synopsys HDMI TX Controller documentation: media: Add documentation for new RGB and YUV bus formats drm: bridge: dw-hdmi: Switch to V4L bus format and encodings drm: bridge: dw-hdmi: Add Documentation on supported input formats drm: bridge: dw-hdmi: Move HPD handling to PHY operations Documentation/gpu/bridge/dw-hdmi.rst| 15 + Documentation/gpu/index.rst | 1 + Documentation/media/uapi/v4l/subdev-formats.rst | 874 +++- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 470 - include/drm/bridge/dw_hdmi.h| 68 ++ include/uapi/linux/media-bus-format.h | 13 +- 6 files changed, 1268 insertions(+), 173 deletions(-) create mode 100644 Documentation/gpu/bridge/dw-hdmi.rst -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
