* [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Matthias Brugger @ 2017-01-13 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113151747.6bc85245@bbrezillon>
On 13/01/17 15:17, Boris Brezillon wrote:
> On Fri, 13 Jan 2017 15:13:29 +0800
> Guochun Mao <guochun.mao@mediatek.com> wrote:
>
>> Add Mediatek nor flash node.
>>
>> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
>> ---
>> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
>> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
>> 2 files changed, 37 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
>> index 082ca88..85e5ae8 100644
>> --- a/arch/arm/boot/dts/mt2701-evb.dts
>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
>> @@ -24,6 +24,31 @@
>> };
>> };
>>
>> +&nor_flash {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&nor_pins_default>;
>> + status = "okay";
>> + flash at 0 {
>> + compatible = "jedec,spi-nor";
>> + reg = <0>;
>> + };
>> +};
>> +
>> +&pio {
>> + nor_pins_default: nor {
>> + pins1 {
>> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
>> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
>> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
>> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
>> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
>> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
>> + drive-strength = <MTK_DRIVE_4mA>;
>> + bias-pull-up;
>> + };
>> + };
>> +};
>> +
>> &uart0 {
>> status = "okay";
>> };
>> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
>> index bdf8954..1eefce4 100644
>> --- a/arch/arm/boot/dts/mt2701.dtsi
>> +++ b/arch/arm/boot/dts/mt2701.dtsi
>> @@ -227,6 +227,18 @@
>> status = "disabled";
>> };
>>
>> + nor_flash: spi at 11014000 {
>> + compatible = "mediatek,mt2701-nor",
>> + "mediatek,mt8173-nor";
>
> Why define both here? Is "mediatek,mt8173-nor" really providing a
> subset of the features supported by "mediatek,mt2701-nor"?
>
I think even if the ip block is the same, we should provide both
bindings, just in case in the future we find out that mt2701 has some
hidden bug, feature or bug-feature. This way even if we update the
driver, we stay compatible with older device tree blobs in the wild.
We can drop the mt2701-nor in the bindings definition if you want.
Regards,
Matthias
>> + reg = <0 0x11014000 0 0xe0>;
>> + clocks = <&pericfg CLK_PERI_FLASH>,
>> + <&topckgen CLK_TOP_FLASH_SEL>;
>> + clock-names = "spi", "sf";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + status = "disabled";
>> + };
>> +
>> mmsys: syscon at 14000000 {
>> compatible = "mediatek,mt2701-mmsys", "syscon";
>> reg = <0 0x14000000 0 0x1000>;
>
^ permalink raw reply
* [PATCH v3 3/5] arm64: Create and use __tlbi_dsb() macros
From: Christopher Covington @ 2017-01-13 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112165852.GH13843@arm.com>
Hi Will,
On 01/12/2017 11:58 AM, Will Deacon wrote:
> Hi Christopher,
>
> On Wed, Jan 11, 2017 at 09:41:16AM -0500, Christopher Covington wrote:
>> This refactoring will allow an errata workaround that repeats tlbi dsb
>> sequences to only change one location. This is not intended to change the
>> generated assembly and comparison of before and after preprocessor output
>> of arch/arm64/mm/mmu.c and vmlinux objdump shows no functional changes.
>>
>> Signed-off-by: Christopher Covington <cov@codeaurora.org>
>> ---
>> arch/arm64/include/asm/tlbflush.h | 104 +++++++++++++++++++++++++-------------
>> 1 file changed, 69 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
>> index deab523..f28813c 100644
>> --- a/arch/arm64/include/asm/tlbflush.h
>> +++ b/arch/arm64/include/asm/tlbflush.h
>> @@ -25,22 +25,69 @@
>> #include <asm/cputype.h>
>>
>> /*
>> - * Raw TLBI operations.
>> + * Raw TLBI, DSB operations
>> *
>> - * Where necessary, use the __tlbi() macro to avoid asm()
>> - * boilerplate. Drivers and most kernel code should use the TLB
>> - * management routines in preference to the macro below.
>> + * Where necessary, use __tlbi_*dsb() macros to avoid asm() boilerplate.
>> + * Drivers and most kernel code should use the TLB management routines in
>> + * preference to the macros below.
>> *
>> - * The macro can be used as __tlbi(op) or __tlbi(op, arg), depending
>> - * on whether a particular TLBI operation takes an argument or
>> - * not. The macros handles invoking the asm with or without the
>> - * register argument as appropriate.
>> + * The __tlbi_dsb() macro handles invoking the asm without any register
>> + * argument, with a single register argument, and with start (included)
>> + * and end (excluded) range of register arguments. For example:
>> + *
>> + * __tlbi_dsb(op, attr)
>> + *
>> + * tlbi op
>> + * dsb attr
>> + *
>> + * __tlbi_dsb(op, attr, addr)
>> + *
>> + * mov %[addr], =addr
>> + * tlbi op, %[addr]
>> + * dsb attr
>> + *
>> + * __tlbi_range_dsb(op, attr, start, end)
>> + *
>> + * mov %[arg], =start
>> + * mov %[end], =end
>> + * for:
>> + * tlbi op, %[addr]
>> + * add %[addr], %[addr], #(1 << (PAGE_SHIFT - 12))
>> + * cmp %[addr], %[end]
>> + * b.ne for
>> + * dsb attr
>> */
>> -#define __TLBI_0(op, arg) asm ("tlbi " #op)
>> -#define __TLBI_1(op, arg) asm ("tlbi " #op ", %0" : : "r" (arg))
>> -#define __TLBI_N(op, arg, n, ...) __TLBI_##n(op, arg)
>>
>> -#define __tlbi(op, ...) __TLBI_N(op, ##__VA_ARGS__, 1, 0)
>> +#define __TLBI_FOR_0(ig0, ig1, ig2)
>> +#define __TLBI_INSTR_0(op, ig1, ig2) "tlbi " #op
>> +#define __TLBI_IO_0(ig0, ig1, ig2) : :
>> +
>> +#define __TLBI_FOR_1(ig0, ig1, ig2)
>> +#define __TLBI_INSTR_1(op, ig0, ig1) "tlbi " #op ", %0"
>> +#define __TLBI_IO_1(ig0, arg, ig1) : : "r" (arg)
>> +
>> +#define __TLBI_FOR_2(ig0, start, ig1) unsigned long addr; \
>> + for (addr = start; addr < end; \
>> + addr += 1 << (PAGE_SHIFT - 12))
>> +#define __TLBI_INSTR_2(op, ig0, ig1) "tlbi " #op ", %0"
>> +#define __TLBI_IO_2(ig0, ig1, ig2) : : "r" (addr)
>> +
>> +#define __TLBI_FOR_N(op, a1, a2, n, ...) __TLBI_FOR_##n(op, a1, a2)
>> +#define __TLBI_INSTR_N(op, a1, a2, n, ...) __TLBI_INSTR_##n(op, a1, a2)
>> +#define __TLBI_IO_N(op, a1, a2, n, ...) __TLBI_IO_##n(op, a1, a2)
>> +
>> +#define __TLBI_FOR(op, ...) __TLBI_FOR_N(op, ##__VA_ARGS__, 2, 1, 0)
>> +#define __TLBI_INSTR(op, ...) __TLBI_INSTR_N(op, ##__VA_ARGS__, 2, 1, 0)
>> +#define __TLBI_IO(op, ...) __TLBI_IO_N(op, ##__VA_ARGS__, 2, 1, 0)
>> +
>> +#define __tlbi_asm_dsb(as, op, attr, ...) do { \
>> + __TLBI_FOR(op, ##__VA_ARGS__) \
>> + asm (__TLBI_INSTR(op, ##__VA_ARGS__) \
>> + __TLBI_IO(op, ##__VA_ARGS__)); \
>> + asm volatile ( as "\ndsb " #attr "\n" \
>> + : : : "memory"); } while (0)
>> +
>> +#define __tlbi_dsb(...) __tlbi_asm_dsb("", ##__VA_ARGS__)
>
> I can't deny that this is cool, but ultimately it's completely unreadable.
> What I was thinking you'd do would be make __tlbi expand to:
>
> tlbi
> dsb
> tlbi
> dsb
>
> for Falkor, and:
>
> tlbi
> nop
> nop
> nop
>
> for everybody else.
Thanks for the suggestion. So would __tlbi take a dsb sharability argument in
your proposal? Or would it be communicated in some other fashion, maybe inferred
from the tlbi argument? Or would the workaround dsbs all be the worst/broadest
case?
> Wouldn't that localise this change sufficiently that you wouldn't need
> to change all the callers and encode the looping in your cpp macros?
>
> I realise you get an extra dsb in some places with that change, but I'd
> like to see numbers for the impact of that on top of the workaround. If
> it's an issue, then an alternative sequence would be:
>
> tlbi
> dsb
> tlbi
>
> and you'd rely on the existing dsb to complete that.
>
> Having said that, I don't understand how your current loop code works
> when the workaround is applied. AFAICT, you end up emitting something
> like:
>
> dsb ishst
> for i in 0 to n
> tlbi va+i
> dsb
> tlbi va+n
> dsb
>
> which looks wrong to me. Am I misreading something here?
You're right, I am off by 1 << (PAGE_SHIFT - 12) here. I would need to
increment, compare, not take the loop branch (regular for loop stuff),
then decrement (missing) and perform TLB invalidation again (present but
using incorrect value).
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v3 16/24] media: Add i.MX media core driver
From: Philipp Zabel @ 2017-01-13 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483755102-24785-17-git-send-email-steve_longerbeam@mentor.com>
Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> Add the core media driver for i.MX SOC.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
> Documentation/media/v4l-drivers/imx.rst | 443 ++++++++++
> drivers/staging/media/Kconfig | 2 +
> drivers/staging/media/Makefile | 1 +
> drivers/staging/media/imx/Kconfig | 8 +
> drivers/staging/media/imx/Makefile | 6 +
> drivers/staging/media/imx/TODO | 22 +
> drivers/staging/media/imx/imx-media-common.c | 981 ++++++++++++++++++++++
> drivers/staging/media/imx/imx-media-dev.c | 486 +++++++++++
> drivers/staging/media/imx/imx-media-fim.c | 471 +++++++++++
> drivers/staging/media/imx/imx-media-internal-sd.c | 457 ++++++++++
> drivers/staging/media/imx/imx-media-of.c | 289 +++++++
> drivers/staging/media/imx/imx-media.h | 310 +++++++
> include/media/imx.h | 15 +
> include/uapi/linux/v4l2-controls.h | 4 +
> 14 files changed, 3495 insertions(+)
> create mode 100644 Documentation/media/v4l-drivers/imx.rst
> create mode 100644 drivers/staging/media/imx/Kconfig
> create mode 100644 drivers/staging/media/imx/Makefile
> create mode 100644 drivers/staging/media/imx/TODO
> create mode 100644 drivers/staging/media/imx/imx-media-common.c
> create mode 100644 drivers/staging/media/imx/imx-media-dev.c
> create mode 100644 drivers/staging/media/imx/imx-media-fim.c
> create mode 100644 drivers/staging/media/imx/imx-media-internal-sd.c
> create mode 100644 drivers/staging/media/imx/imx-media-of.c
> create mode 100644 drivers/staging/media/imx/imx-media.h
> create mode 100644 include/media/imx.h
>
> diff --git a/Documentation/media/v4l-drivers/imx.rst b/Documentation/media/v4l-drivers/imx.rst
> new file mode 100644
> index 0000000..87b37b5
> --- /dev/null
> +++ b/Documentation/media/v4l-drivers/imx.rst
> @@ -0,0 +1,443 @@
> +i.MX Video Capture Driver
> +=========================
> +
> +Introduction
> +------------
> +
> +The Freescale i.MX5/6 contains an Image Processing Unit (IPU), which
> +handles the flow of image frames to and from capture devices and
> +display devices.
> +
> +For image capture, the IPU contains the following internal subunits:
> +
> +- Image DMA Controller (IDMAC)
> +- Camera Serial Interface (CSI)
> +- Image Converter (IC)
> +- Sensor Multi-FIFO Controller (SMFC)
> +- Image Rotator (IRT)
> +- Video De-Interlace Controller (VDIC)
Nitpick: Video De-Interlacing or Combining Block (VDIC)
> +
> +The IDMAC is the DMA controller for transfer of image frames to and from
> +memory. Various dedicated DMA channels exist for both video capture and
> +display paths.
> +
> +The CSI is the frontend capture unit that interfaces directly with
> +capture sensors over Parallel, BT.656/1120, and MIPI CSI-2 busses.
> +
> +The IC handles color-space conversion, resizing, and rotation
> +operations.
And horizontal flipping.
> There are three independent "tasks" within the IC that can
> +carry out conversions concurrently: pre-processing encoding,
> +pre-processing preview, and post-processing.
s/preview/viewfinder/ seems to be the commonly used name.
This paragraph could mention that a single hardware unit is used
transparently time multiplexed by the three tasks at different
granularity for the downsizing, main processing, and rotation sections.
The downscale unit switches between tasks at 8-pixel burst granularity,
the main processing unit at line granularity. The rotation units switch
only at frame granularity.
> +The SMFC is composed of four independent channels that each can transfer
> +captured frames from sensors directly to memory concurrently.
> +
> +The IRT carries out 90 and 270 degree image rotation operations.
... on 8x8 pixel blocks, supported by the IDMAC which handles block
transfers, block reordering, and vertical flipping.
> +The VDIC handles the conversion of interlaced video to progressive, with
> +support for different motion compensation modes (low, medium, and high
> +motion). The deinterlaced output frames from the VDIC can be sent to the
> +IC pre-process preview task for further conversions.
> +
> +In addition to the IPU internal subunits, there are also two units
> +outside the IPU that are also involved in video capture on i.MX:
> +
> +- MIPI CSI-2 Receiver for camera sensors with the MIPI CSI-2 bus
> + interface. This is a Synopsys DesignWare core.
> +- A video multiplexer for selecting among multiple sensor inputs to
> + send to a CSI.
Two of them, actually.
> +For more info, refer to the latest versions of the i.MX5/6 reference
> +manuals listed under References.
> +
> +
> +Features
> +--------
> +
> +Some of the features of this driver include:
> +
> +- Many different pipelines can be configured via media controller API,
> + that correspond to the hardware video capture pipelines supported in
> + the i.MX.
> +
> +- Supports parallel, BT.565, and MIPI CSI-2 interfaces.
> +
> +- Up to four concurrent sensor acquisitions, by configuring each
> + sensor's pipeline using independent entities. This is currently
> + demonstrated with the SabreSD and SabreLite reference boards with
> + independent OV5642 and MIPI CSI-2 OV5640 sensor modules.
> +
> +- Scaling, color-space conversion, and image rotation via IC task
> + subdevs.
> +
> +- Many pixel formats supported (RGB, packed and planar YUV, partial
> + planar YUV).
> +
> +- The IC pre-process preview subdev supports motion compensated
> + de-interlacing using the VDIC, with three motion compensation modes:
> + low, medium, and high motion. The mode is specified with a custom
> + control. Pipelines are defined that allow sending frames to the
> + preview subdev directly from the CSI or from the SMFC.
> +
> +- Includes a Frame Interval Monitor (FIM) that can correct vertical sync
> + problems with the ADV718x video decoders. See below for a description
> + of the FIM.
Could this also be used to calculate more precise capture timestamps?
> +Capture Pipelines
> +-----------------
> +
> +The following describe the various use-cases supported by the pipelines.
> +
> +The links shown do not include the frontend sensor, video mux, or mipi
> +csi-2 receiver links. This depends on the type of sensor interface
> +(parallel or mipi csi-2). So in all cases, these pipelines begin with:
> +
> +sensor -> ipu_csi_mux -> ipu_csi -> ...
> +
> +for parallel sensors, or:
> +
> +sensor -> imx-mipi-csi2 -> (ipu_csi_mux) -> ipu_csi -> ...
> +
> +for mipi csi-2 sensors. The imx-mipi-csi2 receiver may need to route
> +to the video mux (ipu_csi_mux) before sending to the CSI, depending
> +on the mipi csi-2 virtual channel, hence ipu_csi_mux is shown in
> +parenthesis.
> +
> +Unprocessed Video Capture:
> +--------------------------
> +
> +Send frames directly from sensor to camera interface, with no
> +conversions:
> +
> +-> ipu_smfc -> camif
I'd call this capture interface, this is not just for cameras. Or maybe
idmac if you want to mirror hardware names?
> +Note the ipu_smfc can do pixel reordering within the same colorspace.
That isn't a feature of the SMFC, but of the IDMAC (FCW & FCR).
> +For example, its sink pad can take UYVY2X8, but its source pad can
> +output YUYV2X8.
I don't think this is correct. Re-reading "37.4.3.7 Packing to memory"
in the CSI chapter, for 8-bit per component data, the internal format
between CSI, SMFC, and IDMAC is always some 32-bit RGBx/YUVx variant
(or "bayer/generic data"). In either case, the internal format does not
change along the way.
> +IC Direct Conversions:
> +----------------------
> +
> +This pipeline uses the preprocess encode entity to route frames directly
> +from the CSI to the IC (bypassing the SMFC), to carry out scaling up to
> +1024x1024 resolution, CSC, and image rotation:
> +
> +-> ipu_ic_prpenc -> camif
> +
> +This can be a useful capture pipeline for heavily loaded memory bus
> +traffic environments, since it has minimal IDMAC channel usage.
Note that if rotation is enabled, transfers between IC processing and
rotation still have to go through memory once.
> +Post-Processing Conversions:
> +----------------------------
> +
> +This pipeline routes frames from the SMFC to the post-processing
> +entity.
No, frames written by the CSI -> SMFC -> IDMAC path are read back into
the post-processing entity.
> In addition to CSC and rotation, this entity supports tiling
> +which allows scaled output beyond the 1024x1024 limitation of the IC
> +(up to 4096x4096 scaling output is supported):
> +
> +-> ipu_smfc -> ipu_ic_pp -> camif
> +
> +Motion Compensated De-interlace:
> +--------------------------------
> +
> +This pipeline routes frames from the SMFC to the preprocess preview
> +entity to support motion-compensated de-interlacing using the VDIC,
> +scaling up to 1024x1024, and CSC:
> +
> +-> ipu_smfc -> ipu_ic_prpvf -> camif
Same as above.
> +This pipeline also carries out the same conversions as above, but routes
> +frames directly from the CSI to the IC preprocess preview entity for
> +minimal memory bandwidth usage (note: this pipeline only works in
> +"high motion" mode):
> +
> +-> ipu_ic_prpvf -> camif
> +
> +This pipeline takes the motion-compensated de-interlaced frames and
> +sends them to the post-processor, to support motion-compensated
> +de-interlacing, scaling up to 4096x4096, CSC, and rotation:
> +
> +-> (ipu_smfc) -> ipu_ic_prpvf -> ipu_ic_pp -> camif
> +
> +
> +Usage Notes
> +-----------
[...]
> +SabreLite with OV5642 and OV5640
> +--------------------------------
> +
> +This platform requires the OmniVision OV5642 module with a parallel
> +camera interface, and the OV5640 module with a MIPI CSI-2
> +interface. Both modules are available from Boundary Devices:
> +
> +https://boundarydevices.com/products/nit6x_5mp
> +https://boundarydevices.com/product/nit6x_5mp_mipi
> +
> +Note that if only one camera module is available, the other sensor
> +node can be disabled in the device tree.
> +
> +The OV5642 module is connected to the parallel bus input on the i.MX
> +internal video mux to IPU1 CSI0. It's i2c bus connects to i2c bus 2.
> +
> +The MIPI CSI-2 OV5640 module is connected to the i.MX internal MIPI CSI-2
> +receiver, and the four virtual channel outputs from the receiver are
> +routed as follows: vc0 to the IPU1 CSI0 mux, vc1 directly to IPU1 CSI1,
> +vc2 directly to IPU2 CSI0, and vc3 to the IPU2 CSI1 mux. The OV5640 is
> +also connected to i2c bus 2 on the SabreLite, therefore the OV5642 and
> +OV5640 must not share the same i2c slave address.
> +
> +The following basic example configures unprocessed video capture
> +pipelines for both sensors. The OV5642 is routed to camif0
> +(usually /dev/video0), and the OV5640 (transmitting on mipi csi-2
> +virtual channel 1) is routed to camif1 (usually /dev/video1). Both
> +sensors are configured to output 640x480, UYVY (not shown: all pad
> +field types should be set to "NONE"):
> +
> +.. code-block:: none
> +
> + # Setup links for OV5642
> + media-ctl -l '"ov5642 1-0042":0 -> "ipu1_csi0_mux":1[1]'
> + media-ctl -l '"ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]'
> + media-ctl -l '"ipu1_csi0":1 -> "ipu1_smfc0":0[1]'
> + media-ctl -l '"ipu1_smfc0":1 -> "camif0":0[1]'
> + media-ctl -l '"camif0":1 -> "camif0 devnode":0[1]'
> + # Setup links for OV5640
> + media-ctl -l '"ov5640_mipi 1-0040":0 -> "imx-mipi-csi2":0[1]'
> + media-ctl -l '"imx-mipi-csi2":2 -> "ipu1_csi1":0[1]'
> + media-ctl -l '"ipu1_csi1":1 -> "ipu1_smfc1":0[1]'
> + media-ctl -l '"ipu1_smfc1":1 -> "camif1":0[1]'
> + media-ctl -l '"camif1":1 -> "camif1 devnode":0[1]'
> + # Configure pads for OV5642 pipeline
> + media-ctl -V "\"ov5642 1-0042\":0 [fmt:YUYV2X8/640x480]"
> + media-ctl -V "\"ipu1_csi0_mux\":1 [fmt:YUYV2X8/640x480]"
> + media-ctl -V "\"ipu1_csi0_mux\":2 [fmt:YUYV2X8/640x480]"
> + media-ctl -V "\"ipu1_csi0\":0 [fmt:YUYV2X8/640x480]"
> + media-ctl -V "\"ipu1_csi0\":1 [fmt:YUYV2X8/640x480]"
> + media-ctl -V "\"ipu1_smfc0\":0 [fmt:YUYV2X8/640x480]"
> + media-ctl -V "\"ipu1_smfc0\":1 [fmt:UYVY2X8/640x480]"
I think the smfc entities should be dropped.
> + media-ctl -V "\"camif0\":0 [fmt:UYVY2X8/640x480]"
> + media-ctl -V "\"camif0\":1 [fmt:UYVY2X8/640x480]"
> + # Configure pads for OV5640 pipeline
> + media-ctl -V "\"ov5640_mipi 1-0040\":0 [fmt:UYVY2X8/640x480]"
> + media-ctl -V "\"imx-mipi-csi2\":0 [fmt:UYVY2X8/640x480]"
> + media-ctl -V "\"imx-mipi-csi2\":2 [fmt:UYVY2X8/640x480]"
> + media-ctl -V "\"ipu1_csi1\":0 [fmt:UYVY2X8/640x480]"
> + media-ctl -V "\"ipu1_csi1\":1 [fmt:UYVY2X8/640x480]"
[...]
> + media-ctl -V "\"camif1\":0 [fmt:UYVY2X8/640x480]"
I agree this looks very intuitive, but technically correct for the
csi1:1 and camif1:0 pads would be a 32-bit YUV format.
(MEDIA_BUS_FMT_YUV8_1X32_PADLO doesn't exist yet).
I think it would be better to use the correct format as that will allow
to chose the regular vs. companded packings in the future for formats
with more than 8 bits per component.
> + media-ctl -V "\"camif1\":1 [fmt:UYVY2X8/640x480]"
>+
> +Streaming can then begin independently on device nodes /dev/video0
> +and /dev/video1.
> +
> +SabreAuto with ADV7180 decoder
> +------------------------------
> +
> +On the SabreAuto, an on-board ADV7180 SD decoder is connected to the
> +parallel bus input on the internal video mux to IPU1 CSI0.
> +
> +The following example configures a pipeline to capture from the ADV7180
> +video decoder, assuming NTSC 720x480 input signals, with Motion
> +Compensated de-interlacing (not shown: all pad field types should be set
> +as indicated). $outputfmt can be any format supported by the
> +ipu1_ic_prpvf entity at its output pad:
> +
> +.. code-block:: none
> +
> + # Setup links
> + media-ctl -l '"adv7180 3-0021":0 -> "ipu1_csi0_mux":1[1]'
> + media-ctl -l '"ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]'
> + media-ctl -l '"ipu1_csi0":1 -> "ipu1_smfc0":0[1]'
> + media-ctl -l '"ipu1_smfc0":1 -> "ipu1_ic_prpvf":0[1]'
> + media-ctl -l '"ipu1_ic_prpvf":1 -> "camif0":0[1]'
> + media-ctl -l '"camif0":1 -> "camif0 devnode":0[1]'
> + # Configure pads
> + # pad field types for below pads must be an interlaced type
> + # such as "ALTERNATE"
I think alternate should only extend as far as the CSI, since the CSI
can only capture NTSC/PAL fields in a fixed order.
> + media-ctl -V "\"adv7180 3-0021\":0 [fmt:UYVY2X8/720x480]"
> + media-ctl -V "\"ipu1_csi0_mux\":1 [fmt:UYVY2X8/720x480]"
>From here the interlaced field type should be sequential in the correct
order depending on NTSC/PAL.
> + media-ctl -V "\"ipu1_csi0_mux\":2 [fmt:UYVY2X8/720x480]"
> + media-ctl -V "\"ipu1_csi0\":0 [fmt:UYVY2X8/720x480]"
> + media-ctl -V "\"ipu1_csi0\":1 [fmt:UYVY2X8/720x480]"
> + media-ctl -V "\"ipu1_smfc0\":0 [fmt:UYVY2X8/720x480]"
> + media-ctl -V "\"ipu1_smfc0\":1 [fmt:UYVY2X8/720x480]"
> + media-ctl -V "\"ipu1_ic_prpvf\":0 [fmt:UYVY2X8/720x480]"
> + # pad field types for below pads must be "NONE"
> + media-ctl -V "\"ipu1_ic_prpvf\":1 [fmt:$outputfmt]"
> + media-ctl -V "\"camif0\":0 [fmt:$outputfmt]"
> + media-ctl -V "\"camif0\":1 [fmt:$outputfmt]"
> +
> +Streaming can then begin on /dev/video0.
> +
> +This platform accepts Composite Video analog inputs to the ADV7180 on
> +Ain1 (connector J42) and Ain3 (connector J43).
> +
> +To switch to Ain1:
> +
> +.. code-block:: none
> +
> + # v4l2-ctl -i0
> +
> +To switch to Ain3:
> +
> +.. code-block:: none
> +
> + # v4l2-ctl -i1
> +
> +
> +Frame Interval Monitor
> +----------------------
> +
> +The adv718x decoders can occasionally send corrupt fields during
> +NTSC/PAL signal re-sync (too little or too many video lines). When
> +this happens, the IPU triggers a mechanism to re-establish vertical
> +sync by adding 1 dummy line every frame, which causes a rolling effect
> +from image to image, and can last a long time before a stable image is
> +recovered. Or sometimes the mechanism doesn't work at all, causing a
> +permanent split image (one frame contains lines from two consecutive
> +captured images).
Is it only SabreAuto on which the FIM mechanism can be used due to the
pad routing?
[...]
> +/*
> + * DMA buffer ring handling
> + */
> +struct imx_media_dma_buf_ring {
> + struct imx_media_dev *imxmd;
> +
> + /* the ring */
> + struct imx_media_dma_buf buf[IMX_MEDIA_MAX_RING_BUFS];
> + /* the scratch buffer for underruns */
> + struct imx_media_dma_buf scratch;
> +
> + /* buffer generator */
> + struct media_entity *src;
> + /* buffer receiver */
> + struct media_entity *sink;
> +
> + spinlock_t lock;
> +
> + int num_bufs;
> + unsigned long last_seq;
> +};
I don't think this belongs in the capture driver at all.
Memory-to-memory transfers should be handled at the videobuf2 level.
[...]
> +static struct imx_media_dma_buf *
> +__dma_buf_queue(struct imx_media_dma_buf_ring *ring, int index)
> +{
> + struct imx_media_dma_buf *buf;
> +
> + if (index >= ring->num_bufs)
> + return ERR_PTR(-EINVAL);
> +
> + buf = &ring->buf[index];
> + if (WARN_ON(buf->state != IMX_MEDIA_BUF_STATUS_PREPARED))
> + return ERR_PTR(-EINVAL);
> +
> + buf->state = IMX_MEDIA_BUF_STATUS_QUEUED;
> + buf->seq = ring->last_seq++;
> +
> + return buf;
> +}
Is this a whole software buffer queue implementation? I thought the
whole point of putting the custom mem2mem framework into the capture
driver was to use the hardware FSU channel linking?
> +int imx_media_dma_buf_queue(struct imx_media_dma_buf_ring *ring, int index)
> +{
> + struct imx_media_dma_buf *buf;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&ring->lock, flags);
> + buf = __dma_buf_queue(ring, index);
> + spin_unlock_irqrestore(&ring->lock, flags);
> +
> + if (IS_ERR(buf))
> + return PTR_ERR(buf);
> +
> + dev_dbg(ring->imxmd->dev, "buf%d [%s -> %s] queued\n",
> + index, ring->src->name, ring->sink->name);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(imx_media_dma_buf_queue);
> +
> +int imx_media_dma_buf_queue_from_vb(struct imx_media_dma_buf_ring *ring,
> + struct vb2_buffer *vb)
> +{
> + struct imx_media_dma_buf *buf;
> + unsigned long flags;
> + dma_addr_t phys;
> + void *virt;
> +
> + if (vb->index >= ring->num_bufs)
> + return -EINVAL;
> +
> + virt = vb2_plane_vaddr(vb, 0);
> + phys = vb2_dma_contig_plane_dma_addr(vb, 0);
> +
> + spin_lock_irqsave(&ring->lock, flags);
> + buf = __dma_buf_queue(ring, vb->index);
> + if (IS_ERR(buf))
> + goto err_unlock;
> +
> + buf->virt = virt;
> + buf->phys = phys;
> + buf->vb = vb;
> + spin_unlock_irqrestore(&ring->lock, flags);
> +
> + dev_dbg(ring->imxmd->dev, "buf%d [%s -> %s] queued from vb\n",
> + buf->index, ring->src->name, ring->sink->name);
> +
> + return 0;
> +err_unlock:
> + spin_unlock_irqrestore(&ring->lock, flags);
> + return PTR_ERR(buf);
> +}
> +EXPORT_SYMBOL_GPL(imx_media_dma_buf_queue_from_vb);
> +
> +void imx_media_dma_buf_done(struct imx_media_dma_buf *buf,
> + enum imx_media_dma_buf_status status)
> +{
> + struct imx_media_dma_buf_ring *ring = buf->ring;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&ring->lock, flags);
> + WARN_ON(buf->state != IMX_MEDIA_BUF_STATUS_ACTIVE);
> + buf->state = buf->status = status;
> + spin_unlock_irqrestore(&ring->lock, flags);
> +
> + if (buf == &ring->scratch)
> + dev_dbg(ring->imxmd->dev, "buf-scratch [%s -> %s] done\n",
> + ring->src->name, ring->sink->name);
> + else
> + dev_dbg(ring->imxmd->dev, "buf%d [%s -> %s] done\n",
> + buf->index, ring->src->name, ring->sink->name);
> +
> + /* if the sink is a subdev, inform it that new buffers are available */
> + if (is_media_entity_v4l2_subdev(ring->sink)) {
> + struct v4l2_subdev *sd =
> + media_entity_to_v4l2_subdev(ring->sink);
> + v4l2_subdev_call(sd, core, ioctl, IMX_MEDIA_NEW_DMA_BUF, NULL);
What is the purpose of this if the sink should be triggered by the FSU?
[...]
> +/*
> + * The subdevs have to be powered on/off, and streaming
> + * enabled/disabled, in a specific sequence.
> + */
> +static const u32 stream_on_seq[] = {
> + IMX_MEDIA_GRP_ID_IC_PP,
> + IMX_MEDIA_GRP_ID_IC_PRPVF,
> + IMX_MEDIA_GRP_ID_IC_PRPENC,
> + IMX_MEDIA_GRP_ID_SMFC,
> + IMX_MEDIA_GRP_ID_SENSOR,
> + IMX_MEDIA_GRP_ID_CSI2,
> + IMX_MEDIA_GRP_ID_VIDMUX,
> + IMX_MEDIA_GRP_ID_CSI,
> +};
> +
> +static const u32 stream_off_seq[] = {
> + IMX_MEDIA_GRP_ID_IC_PP,
> + IMX_MEDIA_GRP_ID_IC_PRPVF,
> + IMX_MEDIA_GRP_ID_IC_PRPENC,
> + IMX_MEDIA_GRP_ID_SMFC,
> + IMX_MEDIA_GRP_ID_CSI,
> + IMX_MEDIA_GRP_ID_VIDMUX,
> + IMX_MEDIA_GRP_ID_CSI2,
> + IMX_MEDIA_GRP_ID_SENSOR,
> +};
> +
> +#define NUM_STREAM_ENTITIES ARRAY_SIZE(stream_on_seq)
> +
> +static const u32 power_on_seq[] = {
> + IMX_MEDIA_GRP_ID_CSI2,
> + IMX_MEDIA_GRP_ID_SENSOR,
> + IMX_MEDIA_GRP_ID_VIDMUX,
> + IMX_MEDIA_GRP_ID_CSI,
> + IMX_MEDIA_GRP_ID_SMFC,
> + IMX_MEDIA_GRP_ID_IC_PRPENC,
> + IMX_MEDIA_GRP_ID_IC_PRPVF,
> + IMX_MEDIA_GRP_ID_IC_PP,
> +};
> +
> +static const u32 power_off_seq[] = {
> + IMX_MEDIA_GRP_ID_IC_PP,
> + IMX_MEDIA_GRP_ID_IC_PRPVF,
> + IMX_MEDIA_GRP_ID_IC_PRPENC,
> + IMX_MEDIA_GRP_ID_SMFC,
> + IMX_MEDIA_GRP_ID_CSI,
> + IMX_MEDIA_GRP_ID_VIDMUX,
> + IMX_MEDIA_GRP_ID_SENSOR,
> + IMX_MEDIA_GRP_ID_CSI2,
> +};
This seems somewhat arbitrary. Why is a power sequence needed?
[...]
> +/*
> + * Turn current pipeline power on/off starting from start_entity.
> + * Must be called with mdev->graph_mutex held.
> + */
> +int imx_media_pipeline_set_power(struct imx_media_dev *imxmd,
> + struct media_entity_graph *graph,
> + struct media_entity *start_entity, bool on)
> +{
> + struct media_entity *entity;
> + struct v4l2_subdev *sd;
> + int i, ret = 0;
> + u32 id;
> +
> + for (i = 0; i < NUM_POWER_ENTITIES; i++) {
> + id = on ? power_on_seq[i] : power_off_seq[i];
> + entity = find_pipeline_entity(imxmd, graph, start_entity, id);
> + if (!entity)
> + continue;
> +
> + sd = media_entity_to_v4l2_subdev(entity);
> +
> + ret = v4l2_subdev_call(sd, core, s_power, on);
> + if (ret && ret != -ENOIOCTLCMD)
> + break;
> + }
> +
> + return (ret && ret != -ENOIOCTLCMD) ? ret : 0;
> +}
> +EXPORT_SYMBOL_GPL(imx_media_pipeline_set_power);
This should really be handled by v4l2_pipeline_pm_use.
> +/*
> + * Inherit the v4l2 controls from all entities in a pipeline
> + * to the given video device.
> + * Must be called with mdev->graph_mutex held.
> + */
> +int imx_media_inherit_controls(struct imx_media_dev *imxmd,
> + struct video_device *vfd,
> + struct media_entity *start_entity)
> +{
> + struct media_entity_graph graph;
> + struct media_entity *entity;
> + struct v4l2_subdev *sd;
> + int ret;
> +
> + ret = media_entity_graph_walk_init(&graph, &imxmd->md);
> + if (ret)
> + return ret;
> +
> + media_entity_graph_walk_start(&graph, start_entity);
> +
> + while ((entity = media_entity_graph_walk_next(&graph))) {
> + if (is_media_entity_v4l2_video_device(entity))
> + continue;
> +
> + sd = media_entity_to_v4l2_subdev(entity);
> +
> + dev_dbg(imxmd->dev, "%s: adding controls from %s\n",
> + __func__, sd->name);
> +
> + ret = v4l2_ctrl_add_handler(vfd->ctrl_handler,
> + sd->ctrl_handler,
> + NULL);
> + if (ret)
> + break;
> + }
> +
> + media_entity_graph_walk_cleanup(&graph);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(imx_media_inherit_controls);
> +
> +MODULE_DESCRIPTION("i.MX5/6 v4l2 media controller driver");
> +MODULE_AUTHOR("Steve Longerbeam <steve_longerbeam@mentor.com>");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/staging/media/imx/imx-media-dev.c b/drivers/staging/media/imx/imx-media-dev.c
> new file mode 100644
> index 0000000..357654d
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-media-dev.c
This file is full of code that should live in the v4l2 core.
[...]
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-media-internal-sd.c
[...]
> +int imx_media_add_internal_subdevs(struct imx_media_dev *imxmd,
> + struct imx_media_subdev *csi[4])
> +{
> + int ret;
> +
> + /* there must be at least one CSI in first IPU */
Why?
> + if (!(csi[0] || csi[1]))
> + return -EINVAL;
> +
> + ret = add_ipu_internal_subdevs(imxmd, csi[0], csi[1], 0);
> + if (ret)
> + return ret;
> +
> + if (csi[2] || csi[3])
> + ret = add_ipu_internal_subdevs(imxmd, csi[2], csi[3], 1);
> +
> + return ret;
> +}
> diff --git a/drivers/staging/media/imx/imx-media-of.c b/drivers/staging/media/imx/imx-media-of.c
> new file mode 100644
> index 0000000..a939c34
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-media-of.c
> @@ -0,0 +1,289 @@
> +/*
> + * Media driver for Freescale i.MX5/6 SOC
> + *
> + * Open Firmware parsing.
> + *
> + * Copyright (c) 2016 Mentor Graphics Inc.
> + *
> + * 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; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include <linux/of_platform.h>
> +#include <media/v4l2-ctrls.h>
> +#include <media/v4l2-device.h>
> +#include <media/v4l2-of.h>
> +#include <media/v4l2-subdev.h>
> +#include <media/videobuf2-dma-contig.h>
> +#include <video/imx-ipu-v3.h>
> +#include "imx-media.h"
> +
> +static int of_add_pad_link(struct imx_media_dev *imxmd,
> + struct imx_media_pad *pad,
> + struct device_node *local_sd_node,
> + struct device_node *remote_sd_node,
> + int local_pad, int remote_pad)
> +{
> + dev_dbg(imxmd->dev, "%s: adding %s:%d -> %s:%d\n", __func__,
> + local_sd_node->name, local_pad,
> + remote_sd_node->name, remote_pad);
> +
> + return imx_media_add_pad_link(imxmd, pad, remote_sd_node, NULL,
> + local_pad, remote_pad);
> +}
> +
> +/* parse inputs property from a sensor node */
> +static void of_parse_sensor_inputs(struct imx_media_dev *imxmd,
> + struct imx_media_subdev *sensor,
> + struct device_node *sensor_np)
> +{
> + struct imx_media_sensor_input *sinput = &sensor->input;
> + int ret, i;
> +
> + for (i = 0; i < IMX_MEDIA_MAX_SENSOR_INPUTS; i++) {
> + const char *input_name;
> + u32 val;
> +
> + ret = of_property_read_u32_index(sensor_np, "inputs", i, &val);
> + if (ret)
> + break;
> +
> + sinput->value[i] = val;
> +
> + ret = of_property_read_string_index(sensor_np, "input-names",
> + i, &input_name);
> + /*
> + * if input-names not provided, they will be set using
> + * the subdev name once the sensor is known during
> + * async bind
> + */
> + if (!ret)
> + strncpy(sinput->name[i], input_name,
> + sizeof(sinput->name[i]));
> + }
> +
> + sinput->num = i;
> +
> + /* if no inputs provided just assume a single input */
> + if (sinput->num == 0)
> + sinput->num = 1;
> +}
This should be parsed by the sensor driver, not imx-media.
> +static void of_parse_sensor(struct imx_media_dev *imxmd,
> + struct imx_media_subdev *sensor,
> + struct device_node *sensor_np)
> +{
> + struct device_node *endpoint;
> +
> + of_parse_sensor_inputs(imxmd, sensor, sensor_np);
> +
> + endpoint = of_graph_get_next_endpoint(sensor_np, NULL);
> + if (endpoint) {
> + v4l2_of_parse_endpoint(endpoint, &sensor->sensor_ep);
> + of_node_put(endpoint);
> + }
> +}
> +
> +static int of_get_port_count(const struct device_node *np)
> +{
> + struct device_node *child;
> + int num = 0;
> +
> + /* if this node is itself a port, return 1 */
> + if (of_node_cmp(np->name, "port") == 0)
> + return 1;
> +
> + for_each_child_of_node(np, child)
> + if (of_node_cmp(child->name, "port") == 0)
> + num++;
> +
> + return num;
> +}
If this is extended to handle the ports subnode properly, it could be
moved into drivers/of/base.c.
regards
Philipp
^ permalink raw reply
* [GIT PULL 1/4] ARM: exynos: Mach/soc for v4.11
From: Krzysztof Kozlowski @ 2017-01-13 15:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Mostly cleanups for v4.11.
Best regards,
Krzysztof
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-4.11
for you to fetch changes up to cda1a52dab50340728e46601e6c9da9fc4beaf1f:
ARM: s3c64xx: Constify wake_irqs (2016-12-29 15:41:44 +0200)
----------------------------------------------------------------
Samsung mach/soc update for v4.11. Mostly cleanups:
1. Removal of unused platform data in S3C24XX and S3C64xx as follow up of
conversion to new DMA channel request API.
2. Adding const and __ro_after_init to various data in Samsung platforms.
----------------------------------------------------------------
Krzysztof Kozlowski (7):
ARM: EXYNOS: Constify list of retention registers
ARM: EXYNOS: Annotate iomem and pm_data pointers __ro_after_init
ARM: s3c24xx: Constify few integer tables
ARM: s3c64xx: Annotate external clock frequencies __ro_after_init
ARM: SAMSUNG: Constify array of wake irqs passed to samsung_sync_wakemask
ARM: s3c24xx: Constify wake_irqs
ARM: s3c64xx: Constify wake_irqs
Sylwester Nawrocki (2):
ARM: s3c64xx: Drop initialization of unused struct s3c_audio_pdata fields
ARM: s3c24xx: Drop unused struct s3c_audio_pdata entries
arch/arm/mach-exynos/exynos.c | 4 ++--
arch/arm/mach-exynos/mcpm-exynos.c | 2 +-
arch/arm/mach-exynos/suspend.c | 10 +++++-----
arch/arm/mach-s3c24xx/bast-irq.c | 4 ++--
arch/arm/mach-s3c24xx/iotiming-s3c2410.c | 2 +-
arch/arm/mach-s3c24xx/pm-s3c2412.c | 2 +-
arch/arm/mach-s3c64xx/common.c | 3 ++-
arch/arm/mach-s3c64xx/dev-audio.c | 19 -------------------
arch/arm/mach-s3c64xx/pm.c | 2 +-
arch/arm/plat-samsung/devs.c | 19 -------------------
arch/arm/plat-samsung/include/plat/wakeup-mask.h | 2 +-
arch/arm/plat-samsung/wakeup-mask.c | 2 +-
12 files changed, 17 insertions(+), 54 deletions(-)
^ permalink raw reply
* [GIT PULL 2/4] ARM: dts: exynos: DT for v4.11
From: Krzysztof Kozlowski @ 2017-01-13 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113152030.13586-1-krzk@kernel.org>
Hi,
Few improvements and Exynos4412 DTSI removal.
This pulls external dependecy from clock tree (one clock commit).
Best regards,
Krzysztof
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-4.11
for you to fetch changes up to bca9085e0ae93253bc93ce218c85ac7d7e7f1831:
ARM: dts: exynos: remove Exynos4212 support (dead code) (2017-01-11 18:28:43 +0200)
----------------------------------------------------------------
Samsung DeviceTree update for v4.11:
1. Fixes for initial audio clocks configuration.
2. Enable sound on Odroid-X board.
3. Enable DMA for UART modules on Exynos5 SoCs.
4. Add CPU OPPs for Exynos4412 Prime (newer version of Exynos4412). This pulls
necessary change in the clocks.
5. Remove Exynos4212. We do not have any mainline boards with it. This will
simplify few bits later.
----------------------------------------------------------------
Bartlomiej Zolnierkiewicz (2):
clk: samsung: Add CPU clk configuration data for Exynos4412 Prime
ARM: dts: exynos: Add CPU OPPs for Exynos4412 Prime
Krzysztof Kozlowski (1):
Merge tag 'clk-v4.11-exynos4-pll' of git://linuxtv.org/snawrocki/samsung into next/dt
Marek Szyprowski (4):
ARM: dts: exynos: Correct clocks for Exynos4 I2S module
ARM: dts: exynos: Fix initial audio clocks configuration on Exynos4 boards
ARM: dts: exynos: Enable DMA support for UART modules on Exynos5 SoCs
ARM: dts: exynos: remove Exynos4212 support (dead code)
Markus Reichl (1):
ARM: dts: exynos: Cleanup Odroid-X2 and enable sound on Odroid-X
arch/arm/boot/dts/exynos4.dtsi | 6 +-
arch/arm/boot/dts/exynos4212.dtsi | 133 -----
arch/arm/boot/dts/exynos4412-itop-elite.dts | 25 +-
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 28 +-
arch/arm/boot/dts/exynos4412-odroidu3.dts | 5 +-
arch/arm/boot/dts/exynos4412-odroidx.dts | 13 +
arch/arm/boot/dts/exynos4412-odroidx2.dts | 25 +-
...os4x12-pinctrl.dtsi => exynos4412-pinctrl.dtsi} | 4 +-
arch/arm/boot/dts/exynos4412-prime.dtsi | 41 ++
arch/arm/boot/dts/exynos4412.dtsi | 577 +++++++++++++++++++-
arch/arm/boot/dts/exynos4x12.dtsi | 594 ---------------------
arch/arm/boot/dts/exynos5250.dtsi | 8 +
arch/arm/boot/dts/exynos5410.dtsi | 8 +
arch/arm/boot/dts/exynos5420.dtsi | 8 +
drivers/clk/samsung/clk-exynos4.c | 4 +
15 files changed, 685 insertions(+), 794 deletions(-)
delete mode 100644 arch/arm/boot/dts/exynos4212.dtsi
rename arch/arm/boot/dts/{exynos4x12-pinctrl.dtsi => exynos4412-pinctrl.dtsi} (99%)
create mode 100644 arch/arm/boot/dts/exynos4412-prime.dtsi
delete mode 100644 arch/arm/boot/dts/exynos4x12.dtsi
^ permalink raw reply
* [GIT PULL 3/4] arm64: dts: exynos: DT for v4.11
From: Krzysztof Kozlowski @ 2017-01-13 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113152030.13586-1-krzk@kernel.org>
Hi,
Important:
1. Unlike others, this is rebased on v4.10-rc2 because v4.10-rc1 was not
building on arm64.
2. This contains pinctrl change (in header), acked by Linus Walleij.
Although I kept it on separate branch and merged here, but I did not
prepare a separate pull request for this one pinctrl change - it is
just one patch. Anyway it sits on separate branch so this is still
possible if you need it.
Best regards,
Krzysztof
Cc: Linus Walleij <linus.walleij@linaro.org>
The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.11
for you to fetch changes up to e4e381133241a27d732e78be09973b89a193eaf7:
arm64: dts: exynos: Enable HDMI/TV path on Exynos5433-TM2 (2017-01-11 18:20:28 +0200)
----------------------------------------------------------------
Samsung DeviceTree ARM64 update for v4.11:
1. Add bus frequency and voltage scalling on Exynos5433 TM2 device (along with
necessary bus nodes and Platform Performance Monitoring Unit on Exynos5433).
2. Use macros for pinctrl settings on Exynos5433.
This contains necessary header with bindings.
3. Minor cleanups in Exynos5433 DTSI and boards using it.
4. Create common DTSI betweem Exynos5433 TM2E and TM2E.
5. Add HDMI/TV to Exynos5433 TM2.
----------------------------------------------------------------
Andi Shyti (4):
pinctrl: dt-bindings: samsung: add drive strength macros for Exynos5433
arm64: dts: exynos: Use macros for pinctrl configuration on Exynos5433
arm64: dts: exynos: Comply to the samsung pinctrl naming convention in TM2
arm64: dts: exynos: Make TM2 and TM2E independent from each other
Andrzej Hajda (4):
arm64: dts: exynos: Fix addresses in node names on Exynos5433
arm64: dts: exynos: Add DECON_TV node to Exynos5433
arm64: dts: exynos: Add HDMI node to Exynos5433
arm64: dts: exynos: Enable HDMI/TV path on Exynos5433-TM2
Chanwoo Choi (4):
arm64: dts: exynos: Add PPMU node to Exynos5433
arm64: dts: exynos: Add bus nodes using VDD_INT for Exynos5433
arm64: dts: exynos: Add support of bus frequency using VDD_INT on Exynos5433 TM2
arm64: dts: exynos: Fix wrong values for ldo23 and ldo25 on TM2/TM2E
Krzysztof Kozlowski (2):
Merge branch 'for-v4.11/pinctrl-macros' into next/dt64
arm64: dts: exynos: Remove unsupported regulator-always-off property from TM2E
arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 197 ++++
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 373 +++---
.../boot/dts/exynos/exynos5433-tm2-common.dtsi | 1187 ++++++++++++++++++++
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1036 +----------------
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 12 +-
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 115 +-
include/dt-bindings/pinctrl/samsung.h | 14 +
7 files changed, 1695 insertions(+), 1239 deletions(-)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
^ permalink raw reply
* [GIT PULL 4/4] ARM: defconfig: exynos: Defconfig for v4.11
From: Krzysztof Kozlowski @ 2017-01-13 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113152030.13586-1-krzk@kernel.org>
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-4.11
for you to fetch changes up to 74b0ee7579f279dae053053008d29f10f3890c07:
ARM: exynos_defconfig: Enable IP multicast (2016-12-29 16:04:57 +0200)
----------------------------------------------------------------
Samsung defconfig update for v4.11:
1. Cleanup from old MACHs in s5pv210.
2. Enable IP_MULTICAST for libnss-mdns.
----------------------------------------------------------------
Krzysztof Kozlowski (1):
ARM: s5pv210_defconfig: Remove old MACHs
Robie Basak (1):
ARM: exynos_defconfig: Enable IP multicast
arch/arm/configs/exynos_defconfig | 1 +
arch/arm/configs/s5pv210_defconfig | 4 ----
2 files changed, 1 insertion(+), 4 deletions(-)
^ permalink raw reply
* [PATCH RFC 0/7] Clean up PHY MMD accessors
From: Russell King - ARM Linux @ 2017-01-13 15:20 UTC (permalink / raw)
To: linux-arm-kernel
This series cleans up phylib's MMD accessors, so that we have a common
way of accessing the Clause 45 register set.
The current situation is far from ideal - we have phy_(read|write)_mmd()
which accesses Clause 45 registers over Clause 45 accesses, and we have
phy_(read|write)_mmd_indirect(), which accesses Clause 45 registers via
Clause 22 register 13/14.
Generic code uses the indirect methods to access standard Clause 45
features, and when we come to add Clause 45 PHY support to phylib, we
would need to make these conditional upon the PHY type, or duplicate
these functions.
An alternative solution is to merge these accessors together, and select
the appropriate access method depending upon the 802.3 clause that the
PHY conforms with. The result is that we have a single set of
phy_(read|write)_mmd() accessors.
For cases which require special handling, we still allow PHY drivers to
override all MMD accesses - except rather than just overriding the
indirect accesses. This keeps existing overrides working.
Combining the two also has another beneficial side effect - we get rid
of similar functions that take arguments in different orders. The
old direct accessors took the phy structure, devad and register number,
whereas the indirect accessors took the phy structure, register number
and devad in that order. Care must be taken when updating future
drivers that the argument order is correct, and the function name is
not merely replaced.
This patch set is against 4.10-rc3 at present.
drivers/net/phy/Makefile | 3 +-
drivers/net/phy/bcm-phy-lib.c | 12 ++---
drivers/net/phy/dp83867.c | 18 +++----
drivers/net/phy/intel-xway.c | 26 +++++-----
drivers/net/phy/micrel.c | 13 +++--
drivers/net/phy/microchip.c | 5 +-
drivers/net/phy/phy-core.c | 101 ++++++++++++++++++++++++++++++++++++++
drivers/net/phy/phy.c | 110 ++++--------------------------------------
drivers/net/phy/phy_device.c | 4 +-
drivers/net/usb/lan78xx.c | 10 ++--
include/linux/phy.h | 56 +++++++++------------
11 files changed, 176 insertions(+), 182 deletions(-)
create mode 100644 drivers/net/phy/phy-core.c
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-13 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d7b866ad-5b2f-62d3-3aa3-6fa42803d625@gmail.com>
On Fri, 13 Jan 2017 16:12:20 +0100
Matthias Brugger <matthias.bgg@gmail.com> wrote:
> On 13/01/17 15:17, Boris Brezillon wrote:
> > On Fri, 13 Jan 2017 15:13:29 +0800
> > Guochun Mao <guochun.mao@mediatek.com> wrote:
> >
> >> Add Mediatek nor flash node.
> >>
> >> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> >> ---
> >> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
> >> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
> >> 2 files changed, 37 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
> >> index 082ca88..85e5ae8 100644
> >> --- a/arch/arm/boot/dts/mt2701-evb.dts
> >> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> >> @@ -24,6 +24,31 @@
> >> };
> >> };
> >>
> >> +&nor_flash {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&nor_pins_default>;
> >> + status = "okay";
> >> + flash at 0 {
> >> + compatible = "jedec,spi-nor";
> >> + reg = <0>;
> >> + };
> >> +};
> >> +
> >> +&pio {
> >> + nor_pins_default: nor {
> >> + pins1 {
> >> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
> >> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
> >> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
> >> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
> >> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
> >> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
> >> + drive-strength = <MTK_DRIVE_4mA>;
> >> + bias-pull-up;
> >> + };
> >> + };
> >> +};
> >> +
> >> &uart0 {
> >> status = "okay";
> >> };
> >> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> >> index bdf8954..1eefce4 100644
> >> --- a/arch/arm/boot/dts/mt2701.dtsi
> >> +++ b/arch/arm/boot/dts/mt2701.dtsi
> >> @@ -227,6 +227,18 @@
> >> status = "disabled";
> >> };
> >>
> >> + nor_flash: spi at 11014000 {
> >> + compatible = "mediatek,mt2701-nor",
> >> + "mediatek,mt8173-nor";
> >
> > Why define both here? Is "mediatek,mt8173-nor" really providing a
> > subset of the features supported by "mediatek,mt2701-nor"?
> >
>
> I think even if the ip block is the same, we should provide both
> bindings, just in case in the future we find out that mt2701 has some
> hidden bug, feature or bug-feature. This way even if we update the
> driver, we stay compatible with older device tree blobs in the wild.
I'm fine with this approach, but in this case, defining both is wrong.
>
> We can drop the mt2701-nor in the bindings definition if you want.
Yes, please.
>
> Regards,
> Matthias
>
> >> + reg = <0 0x11014000 0 0xe0>;
> >> + clocks = <&pericfg CLK_PERI_FLASH>,
> >> + <&topckgen CLK_TOP_FLASH_SEL>;
> >> + clock-names = "spi", "sf";
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + status = "disabled";
> >> + };
> >> +
> >> mmsys: syscon at 14000000 {
> >> compatible = "mediatek,mt2701-mmsys", "syscon";
> >> reg = <0 0x14000000 0 0x1000>;
> >
^ permalink raw reply
* [PATCH RFC 1/7] net: phy: move phy MMD accessors to phy-core.c
From: Russell King @ 2017-01-13 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113152059.GR14217@n2100.armlinux.org.uk>
Move the phy_(read|write)__mmd() helpers out of line, they will become
our main MMD accessor functions, and so will be a little more complex.
This complexity doesn't belong in an inline function. Also move the
_indirect variants as well to keep like functionality together.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/phy/Makefile | 3 +-
drivers/net/phy/phy-core.c | 135 +++++++++++++++++++++++++++++++++++++++++++++
drivers/net/phy/phy.c | 85 ----------------------------
include/linux/phy.h | 20 +------
4 files changed, 139 insertions(+), 104 deletions(-)
create mode 100644 drivers/net/phy/phy-core.c
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 356859ac7c18..06fa2e04ac7e 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -1,6 +1,7 @@
# Makefile for Linux PHY drivers and MDIO bus drivers
-libphy-y := phy.o phy_device.o mdio_bus.o mdio_device.o
+libphy-y := phy.o phy_device.o mdio_bus.o mdio_device.o \
+ phy-core.o
libphy-$(CONFIG_SWPHY) += swphy.o
libphy-$(CONFIG_LED_TRIGGER_PHY) += phy_led_triggers.o
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
new file mode 100644
index 000000000000..b8d8276a3099
--- /dev/null
+++ b/drivers/net/phy/phy-core.c
@@ -0,0 +1,135 @@
+/*
+ * Core PHY library, taken from phy.c
+ *
+ * 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; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#include <linux/export.h>
+#include <linux/phy.h>
+
+static inline void mmd_phy_indirect(struct mii_bus *bus, int prtad, int devad,
+ int addr)
+{
+ /* Write the desired MMD Devad */
+ bus->write(bus, addr, MII_MMD_CTRL, devad);
+
+ /* Write the desired MMD register address */
+ bus->write(bus, addr, MII_MMD_DATA, prtad);
+
+ /* Select the Function : DATA with no post increment */
+ bus->write(bus, addr, MII_MMD_CTRL, (devad | MII_MMD_CTRL_NOINCR));
+}
+
+/**
+ * phy_read_mmd_indirect - reads data from the MMD registers
+ * @phydev: The PHY device bus
+ * @prtad: MMD Address
+ * @devad: MMD DEVAD
+ *
+ * Description: it reads data from the MMD registers (clause 22 to access to
+ * clause 45) of the specified phy address.
+ * To read these register we have:
+ * 1) Write reg 13 // DEVAD
+ * 2) Write reg 14 // MMD Address
+ * 3) Write reg 13 // MMD Data Command for MMD DEVAD
+ * 3) Read reg 14 // Read MMD data
+ */
+int phy_read_mmd_indirect(struct phy_device *phydev, int prtad, int devad)
+{
+ struct phy_driver *phydrv = phydev->drv;
+ int addr = phydev->mdio.addr;
+ int value = -1;
+
+ if (!phydrv->read_mmd_indirect) {
+ struct mii_bus *bus = phydev->mdio.bus;
+
+ mutex_lock(&bus->mdio_lock);
+ mmd_phy_indirect(bus, prtad, devad, addr);
+
+ /* Read the content of the MMD's selected register */
+ value = bus->read(bus, addr, MII_MMD_DATA);
+ mutex_unlock(&bus->mdio_lock);
+ } else {
+ value = phydrv->read_mmd_indirect(phydev, prtad, devad, addr);
+ }
+ return value;
+}
+EXPORT_SYMBOL(phy_read_mmd_indirect);
+
+/**
+ * phy_read_mmd - Convenience function for reading a register
+ * from an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ *
+ * Same rules as for phy_read();
+ */
+int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
+{
+ if (!phydev->is_c45)
+ return -EOPNOTSUPP;
+
+ return mdiobus_read(phydev->mdio.bus, phydev->mdio.addr,
+ MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff));
+}
+EXPORT_SYMBOL(phy_read_mmd);
+
+/**
+ * phy_write_mmd_indirect - writes data to the MMD registers
+ * @phydev: The PHY device
+ * @prtad: MMD Address
+ * @devad: MMD DEVAD
+ * @data: data to write in the MMD register
+ *
+ * Description: Write data from the MMD registers of the specified
+ * phy address.
+ * To write these register we have:
+ * 1) Write reg 13 // DEVAD
+ * 2) Write reg 14 // MMD Address
+ * 3) Write reg 13 // MMD Data Command for MMD DEVAD
+ * 3) Write reg 14 // Write MMD data
+ */
+void phy_write_mmd_indirect(struct phy_device *phydev, int prtad,
+ int devad, u32 data)
+{
+ struct phy_driver *phydrv = phydev->drv;
+ int addr = phydev->mdio.addr;
+
+ if (!phydrv->write_mmd_indirect) {
+ struct mii_bus *bus = phydev->mdio.bus;
+
+ mutex_lock(&bus->mdio_lock);
+ mmd_phy_indirect(bus, prtad, devad, addr);
+
+ /* Write the data into MMD's selected register */
+ bus->write(bus, addr, MII_MMD_DATA, data);
+ mutex_unlock(&bus->mdio_lock);
+ } else {
+ phydrv->write_mmd_indirect(phydev, prtad, devad, addr, data);
+ }
+}
+EXPORT_SYMBOL(phy_write_mmd_indirect);
+
+/**
+ * phy_write_mmd - Convenience function for writing a register
+ * on an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ * @val: value to write to @regnum
+ *
+ * Same rules as for phy_write();
+ */
+int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
+{
+ if (!phydev->is_c45)
+ return -EOPNOTSUPP;
+
+ regnum = MII_ADDR_C45 | ((devad & 0x1f) << 16) | (regnum & 0xffff);
+
+ return mdiobus_write(phydev->mdio.bus, phydev->mdio.addr, regnum, val);
+}
+EXPORT_SYMBOL(phy_write_mmd);
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 25f93a98863b..c6022b66f81d 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1175,91 +1175,6 @@ void phy_mac_interrupt(struct phy_device *phydev, int new_link)
}
EXPORT_SYMBOL(phy_mac_interrupt);
-static inline void mmd_phy_indirect(struct mii_bus *bus, int prtad, int devad,
- int addr)
-{
- /* Write the desired MMD Devad */
- bus->write(bus, addr, MII_MMD_CTRL, devad);
-
- /* Write the desired MMD register address */
- bus->write(bus, addr, MII_MMD_DATA, prtad);
-
- /* Select the Function : DATA with no post increment */
- bus->write(bus, addr, MII_MMD_CTRL, (devad | MII_MMD_CTRL_NOINCR));
-}
-
-/**
- * phy_read_mmd_indirect - reads data from the MMD registers
- * @phydev: The PHY device bus
- * @prtad: MMD Address
- * @devad: MMD DEVAD
- *
- * Description: it reads data from the MMD registers (clause 22 to access to
- * clause 45) of the specified phy address.
- * To read these register we have:
- * 1) Write reg 13 // DEVAD
- * 2) Write reg 14 // MMD Address
- * 3) Write reg 13 // MMD Data Command for MMD DEVAD
- * 3) Read reg 14 // Read MMD data
- */
-int phy_read_mmd_indirect(struct phy_device *phydev, int prtad, int devad)
-{
- struct phy_driver *phydrv = phydev->drv;
- int addr = phydev->mdio.addr;
- int value = -1;
-
- if (!phydrv->read_mmd_indirect) {
- struct mii_bus *bus = phydev->mdio.bus;
-
- mutex_lock(&bus->mdio_lock);
- mmd_phy_indirect(bus, prtad, devad, addr);
-
- /* Read the content of the MMD's selected register */
- value = bus->read(bus, addr, MII_MMD_DATA);
- mutex_unlock(&bus->mdio_lock);
- } else {
- value = phydrv->read_mmd_indirect(phydev, prtad, devad, addr);
- }
- return value;
-}
-EXPORT_SYMBOL(phy_read_mmd_indirect);
-
-/**
- * phy_write_mmd_indirect - writes data to the MMD registers
- * @phydev: The PHY device
- * @prtad: MMD Address
- * @devad: MMD DEVAD
- * @data: data to write in the MMD register
- *
- * Description: Write data from the MMD registers of the specified
- * phy address.
- * To write these register we have:
- * 1) Write reg 13 // DEVAD
- * 2) Write reg 14 // MMD Address
- * 3) Write reg 13 // MMD Data Command for MMD DEVAD
- * 3) Write reg 14 // Write MMD data
- */
-void phy_write_mmd_indirect(struct phy_device *phydev, int prtad,
- int devad, u32 data)
-{
- struct phy_driver *phydrv = phydev->drv;
- int addr = phydev->mdio.addr;
-
- if (!phydrv->write_mmd_indirect) {
- struct mii_bus *bus = phydev->mdio.bus;
-
- mutex_lock(&bus->mdio_lock);
- mmd_phy_indirect(bus, prtad, devad, addr);
-
- /* Write the data into MMD's selected register */
- bus->write(bus, addr, MII_MMD_DATA, data);
- mutex_unlock(&bus->mdio_lock);
- } else {
- phydrv->write_mmd_indirect(phydev, prtad, devad, addr, data);
- }
-}
-EXPORT_SYMBOL(phy_write_mmd_indirect);
-
/**
* phy_init_eee - init and check the EEE feature
* @phydev: target phy_device struct
diff --git a/include/linux/phy.h b/include/linux/phy.h
index f7d95f644eed..72acb0233b5f 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -647,14 +647,7 @@ struct phy_fixup {
*
* Same rules as for phy_read();
*/
-static inline int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
-{
- if (!phydev->is_c45)
- return -EOPNOTSUPP;
-
- return mdiobus_read(phydev->mdio.bus, phydev->mdio.addr,
- MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff));
-}
+int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum);
/**
* phy_read_mmd_indirect - reads data from the MMD registers
@@ -748,16 +741,7 @@ static inline bool phy_is_pseudo_fixed_link(struct phy_device *phydev)
*
* Same rules as for phy_write();
*/
-static inline int phy_write_mmd(struct phy_device *phydev, int devad,
- u32 regnum, u16 val)
-{
- if (!phydev->is_c45)
- return -EOPNOTSUPP;
-
- regnum = MII_ADDR_C45 | ((devad & 0x1f) << 16) | (regnum & 0xffff);
-
- return mdiobus_write(phydev->mdio.bus, phydev->mdio.addr, regnum, val);
-}
+int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val);
/**
* phy_write_mmd_indirect - writes data to the MMD registers
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 2/7] net: phy: make phy_(read|write)_mmd() generic MMD accessors
From: Russell King @ 2017-01-13 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113152059.GR14217@n2100.armlinux.org.uk>
Make phy_(read|write)_mmd() generic 802.3 clause 45 register accessors
for both Clause 22 and Clause 45 PHYs, using either the direct register
reading for Clause 45, or the indirect method for Clause 22 PHYs.
Allow this behaviour to be overriden by PHY drivers where necessary.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/phy/phy-core.c | 31 +++++++++++++++++++++++--------
include/linux/phy.h | 24 ++++++++++++++++++++++++
2 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
index b8d8276a3099..b50b3a64cf6a 100644
--- a/drivers/net/phy/phy-core.c
+++ b/drivers/net/phy/phy-core.c
@@ -69,11 +69,18 @@ EXPORT_SYMBOL(phy_read_mmd_indirect);
*/
int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
{
- if (!phydev->is_c45)
- return -EOPNOTSUPP;
+ if (regnum > (u16)~0 || devad > 32)
+ return -EINVAL;
- return mdiobus_read(phydev->mdio.bus, phydev->mdio.addr,
- MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff));
+ if (phydev->drv->read_mmd)
+ return phydev->drv->read_mmd(phydev, devad, regnum);
+
+ if (phydev->is_c45) {
+ u32 addr = MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff);
+ return mdiobus_read(phydev->mdio.bus, phydev->mdio.addr, addr);
+ }
+
+ return phy_read_mmd_indirect(phydev, regnum, devad);
}
EXPORT_SYMBOL(phy_read_mmd);
@@ -125,11 +132,19 @@ EXPORT_SYMBOL(phy_write_mmd_indirect);
*/
int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
{
- if (!phydev->is_c45)
- return -EOPNOTSUPP;
+ if (regnum > (u16)~0 || devad > 32)
+ return -EINVAL;
- regnum = MII_ADDR_C45 | ((devad & 0x1f) << 16) | (regnum & 0xffff);
+ if (phydev->drv->read_mmd)
+ return phydev->drv->write_mmd(phydev, devad, regnum, val);
+
+ if (phydev->is_c45) {
+ u32 addr = MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff);
+
+ return mdiobus_write(phydev->mdio.bus, phydev->mdio.addr,
+ addr, val);
+ }
- return mdiobus_write(phydev->mdio.bus, phydev->mdio.addr, regnum, val);
+ return phy_write_mmd_indirect(phydev, regnum, devad, val);
}
EXPORT_SYMBOL(phy_write_mmd);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 72acb0233b5f..54fa76efb096 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -583,6 +583,30 @@ struct phy_driver {
*/
void (*link_change_notify)(struct phy_device *dev);
+ /*
+ * Phy specific driver override for reading a MMD register.
+ * This function is optional for PHY specific drivers. When
+ * not provided, the default MMD read function will be used
+ * by phy_read_mmd(), which will use either a direct read for
+ * Clause 45 PHYs or an indirect read for Clause 22 PHYs.
+ * devnum is the MMD device number within the PHY device,
+ * regnum is the register within the selected MMD device.
+ */
+ int (*read_mmd)(struct phy_device *dev, int devnum, u16 regnum);
+
+ /*
+ * Phy specific driver override for writing a MMD register.
+ * This function is optional for PHY specific drivers. When
+ * not provided, the default MMD write function will be used
+ * by phy_write_mmd(), which will use either a direct write for
+ * Clause 45 PHYs, or an indirect write for Clause 22 PHYs.
+ * devnum is the MMD device number within the PHY device,
+ * regnum is the register within the selected MMD device.
+ * val is the value to be written.
+ */
+ int (*write_mmd)(struct phy_device *dev, int devnum, u16 regnum,
+ u16 val);
+
/* A function provided by a phy specific driver to override the
* the PHY driver framework support for reading a MMD register
* from the PHY. If not supported, return -1. This function is
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 3/7] net: lan78xx: update for phy_(read|write)_mmd_indirect() removal
From: Russell King @ 2017-01-13 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113152059.GR14217@n2100.armlinux.org.uk>
lan78xx appears to use phylib in a rather weird way, accessing the PHY
partly through phylib, and partly by makign direct accesses to it,
including to the Clause 45 registers. As the indirect MMD accessors are
going away, update this driver to use the plain phy_(read|write)_mmd()
accessors instead.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/usb/lan78xx.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 08f8703e4d54..5e222d47f212 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -1951,10 +1951,10 @@ static int lan8835_fixup(struct phy_device *phydev)
struct lan78xx_net *dev = netdev_priv(phydev->attached_dev);
/* LED2/PME_N/IRQ_N/RGMII_ID pin to IRQ_N mode */
- buf = phy_read_mmd_indirect(phydev, 0x8010, 3);
+ buf = phy_read_mmd(phydev, MDIO_MMD_PCS, 0x8010);
buf &= ~0x1800;
buf |= 0x0800;
- phy_write_mmd_indirect(phydev, 0x8010, 3, buf);
+ phy_write_mmd(phydev, MDIO_MMD_PCS, 0x8010, buf);
/* RGMII MAC TXC Delay Enable */
ret = lan78xx_write_reg(dev, MAC_RGMII_ID,
@@ -1974,11 +1974,11 @@ static int ksz9031rnx_fixup(struct phy_device *phydev)
/* Micrel9301RNX PHY configuration */
/* RGMII Control Signal Pad Skew */
- phy_write_mmd_indirect(phydev, 4, 2, 0x0077);
+ phy_write_mmd(phydev, MDIO_MMD_WIS, 4, 0x0077);
/* RGMII RX Data Pad Skew */
- phy_write_mmd_indirect(phydev, 5, 2, 0x7777);
+ phy_write_mmd(phydev, MDIO_MMD_WIS, 5, 0x7777);
/* RGMII RX Clock Pad Skew */
- phy_write_mmd_indirect(phydev, 8, 2, 0x1FF);
+ phy_write_mmd(phydev, MDIO_MMD_WIS, 8, 0x1FF);
dev->interface = PHY_INTERFACE_MODE_RGMII_RXID;
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 4/7] net: phy: switch remaining users to phy_(read|write)_mmd()
From: Russell King @ 2017-01-13 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113152059.GR14217@n2100.armlinux.org.uk>
Switch everyone over to using phy_read_mmd() and phy_write_mmd() now
that they are able to handle both Clause 22 indirect addressing and
Clause 45 direct addressing methods to the MMD registers.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/phy/bcm-phy-lib.c | 12 ++++--------
drivers/net/phy/dp83867.c | 18 ++++++++----------
drivers/net/phy/intel-xway.c | 26 +++++++++++++-------------
drivers/net/phy/microchip.c | 5 ++---
drivers/net/phy/phy.c | 25 ++++++++++---------------
drivers/net/phy/phy_device.c | 4 ++--
6 files changed, 39 insertions(+), 51 deletions(-)
diff --git a/drivers/net/phy/bcm-phy-lib.c b/drivers/net/phy/bcm-phy-lib.c
index ab9ad689617c..90be6ee42dfa 100644
--- a/drivers/net/phy/bcm-phy-lib.c
+++ b/drivers/net/phy/bcm-phy-lib.c
@@ -201,8 +201,7 @@ int bcm_phy_set_eee(struct phy_device *phydev, bool enable)
int val;
/* Enable EEE at PHY level */
- val = phy_read_mmd_indirect(phydev, BRCM_CL45VEN_EEE_CONTROL,
- MDIO_MMD_AN);
+ val = phy_read_mmd(phydev, MDIO_MMD_AN, BRCM_CL45VEN_EEE_CONTROL);
if (val < 0)
return val;
@@ -211,12 +210,10 @@ int bcm_phy_set_eee(struct phy_device *phydev, bool enable)
else
val &= ~(LPI_FEATURE_EN | LPI_FEATURE_EN_DIG1000X);
- phy_write_mmd_indirect(phydev, BRCM_CL45VEN_EEE_CONTROL,
- MDIO_MMD_AN, (u32)val);
+ phy_write_mmd(phydev, MDIO_MMD_AN, BRCM_CL45VEN_EEE_CONTROL, (u32)val);
/* Advertise EEE */
- val = phy_read_mmd_indirect(phydev, BCM_CL45VEN_EEE_ADV,
- MDIO_MMD_AN);
+ val = phy_read_mmd(phydev, MDIO_MMD_AN, BCM_CL45VEN_EEE_ADV);
if (val < 0)
return val;
@@ -225,8 +222,7 @@ int bcm_phy_set_eee(struct phy_device *phydev, bool enable)
else
val &= ~(MDIO_AN_EEE_ADV_100TX | MDIO_AN_EEE_ADV_1000T);
- phy_write_mmd_indirect(phydev, BCM_CL45VEN_EEE_ADV,
- MDIO_MMD_AN, (u32)val);
+ phy_write_mmd(phydev, MDIO_MMD_AN, BCM_CL45VEN_EEE_ADV, (u32)val);
return 0;
}
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 1b639242f9e2..43a5a22234f1 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -180,8 +180,7 @@ static int dp83867_config_init(struct phy_device *phydev)
if ((phydev->interface >= PHY_INTERFACE_MODE_RGMII_ID) &&
(phydev->interface <= PHY_INTERFACE_MODE_RGMII_RXID)) {
- val = phy_read_mmd_indirect(phydev, DP83867_RGMIICTL,
- DP83867_DEVADDR);
+ val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIICTL);
if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
val |= (DP83867_RGMII_TX_CLK_DELAY_EN | DP83867_RGMII_RX_CLK_DELAY_EN);
@@ -192,25 +191,24 @@ static int dp83867_config_init(struct phy_device *phydev)
if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
val |= DP83867_RGMII_RX_CLK_DELAY_EN;
- phy_write_mmd_indirect(phydev, DP83867_RGMIICTL,
- DP83867_DEVADDR, val);
+ phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIICTL, val);
delay = (dp83867->rx_id_delay |
(dp83867->tx_id_delay << DP83867_RGMII_TX_CLK_DELAY_SHIFT));
- phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
- DP83867_DEVADDR, delay);
+ phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIIDCTL,
+ delay);
if (dp83867->io_impedance >= 0) {
- val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
- DP83867_DEVADDR);
+ val = phy_read_mmd(phydev, DP83867_DEVADDR,
+ DP83867_IO_MUX_CFG);
val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
val |= dp83867->io_impedance &
DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
- phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
- DP83867_DEVADDR, val);
+ phy_write_mmd(phydev, DP83867_DEVADDR,
+ DP83867_IO_MUX_CFG, val);
}
}
diff --git a/drivers/net/phy/intel-xway.c b/drivers/net/phy/intel-xway.c
index b1fd7bb0e4db..55f8c52dd2f1 100644
--- a/drivers/net/phy/intel-xway.c
+++ b/drivers/net/phy/intel-xway.c
@@ -166,13 +166,13 @@ static int xway_gphy_config_init(struct phy_device *phydev)
/* Clear all pending interrupts */
phy_read(phydev, XWAY_MDIO_ISTAT);
- phy_write_mmd_indirect(phydev, XWAY_MMD_LEDCH, MDIO_MMD_VEND2,
- XWAY_MMD_LEDCH_NACS_NONE |
- XWAY_MMD_LEDCH_SBF_F02HZ |
- XWAY_MMD_LEDCH_FBF_F16HZ);
- phy_write_mmd_indirect(phydev, XWAY_MMD_LEDCL, MDIO_MMD_VEND2,
- XWAY_MMD_LEDCH_CBLINK_NONE |
- XWAY_MMD_LEDCH_SCAN_NONE);
+ phy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LEDCH,
+ XWAY_MMD_LEDCH_NACS_NONE |
+ XWAY_MMD_LEDCH_SBF_F02HZ |
+ XWAY_MMD_LEDCH_FBF_F16HZ);
+ phy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LEDCL,
+ XWAY_MMD_LEDCH_CBLINK_NONE |
+ XWAY_MMD_LEDCH_SCAN_NONE);
/**
* In most cases only one LED is connected to this phy, so
@@ -183,12 +183,12 @@ static int xway_gphy_config_init(struct phy_device *phydev)
ledxh = XWAY_MMD_LEDxH_BLINKF_NONE | XWAY_MMD_LEDxH_CON_LINK10XX;
ledxl = XWAY_MMD_LEDxL_PULSE_TXACT | XWAY_MMD_LEDxL_PULSE_RXACT |
XWAY_MMD_LEDxL_BLINKS_NONE;
- phy_write_mmd_indirect(phydev, XWAY_MMD_LED0H, MDIO_MMD_VEND2, ledxh);
- phy_write_mmd_indirect(phydev, XWAY_MMD_LED0L, MDIO_MMD_VEND2, ledxl);
- phy_write_mmd_indirect(phydev, XWAY_MMD_LED1H, MDIO_MMD_VEND2, ledxh);
- phy_write_mmd_indirect(phydev, XWAY_MMD_LED1L, MDIO_MMD_VEND2, ledxl);
- phy_write_mmd_indirect(phydev, XWAY_MMD_LED2H, MDIO_MMD_VEND2, ledxh);
- phy_write_mmd_indirect(phydev, XWAY_MMD_LED2L, MDIO_MMD_VEND2, ledxl);
+ phy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED0H, ledxh);
+ phy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED0L, ledxl);
+ phy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED1H, ledxh);
+ phy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED1L, ledxl);
+ phy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED2H, ledxh);
+ phy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED2L, ledxl);
return 0;
}
diff --git a/drivers/net/phy/microchip.c b/drivers/net/phy/microchip.c
index 324fbf6ad8ff..2b2f543cf9f0 100644
--- a/drivers/net/phy/microchip.c
+++ b/drivers/net/phy/microchip.c
@@ -78,9 +78,8 @@ static int lan88xx_probe(struct phy_device *phydev)
priv->wolopts = 0;
/* these values can be used to identify internal PHY */
- priv->chip_id = phy_read_mmd_indirect(phydev, LAN88XX_MMD3_CHIP_ID, 3);
- priv->chip_rev = phy_read_mmd_indirect(phydev, LAN88XX_MMD3_CHIP_REV,
- 3);
+ priv->chip_id = phy_read_mmd(phydev, 3, LAN88XX_MMD3_CHIP_ID);
+ priv->chip_rev = phy_read_mmd(phydev, 3, LAN88XX_MMD3_CHIP_REV);
phydev->priv = priv;
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index c6022b66f81d..e97fda83726a 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1207,8 +1207,7 @@ int phy_init_eee(struct phy_device *phydev, bool clk_stop_enable)
return status;
/* First check if the EEE ability is supported */
- eee_cap = phy_read_mmd_indirect(phydev, MDIO_PCS_EEE_ABLE,
- MDIO_MMD_PCS);
+ eee_cap = phy_read_mmd(phydev, MDIO_MMD_PCS, MDIO_PCS_EEE_ABLE);
if (eee_cap <= 0)
goto eee_exit_err;
@@ -1219,13 +1218,11 @@ int phy_init_eee(struct phy_device *phydev, bool clk_stop_enable)
/* Check which link settings negotiated and verify it in
* the EEE advertising registers.
*/
- eee_lp = phy_read_mmd_indirect(phydev, MDIO_AN_EEE_LPABLE,
- MDIO_MMD_AN);
+ eee_lp = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_LPABLE);
if (eee_lp <= 0)
goto eee_exit_err;
- eee_adv = phy_read_mmd_indirect(phydev, MDIO_AN_EEE_ADV,
- MDIO_MMD_AN);
+ eee_adv = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV);
if (eee_adv <= 0)
goto eee_exit_err;
@@ -1238,14 +1235,12 @@ int phy_init_eee(struct phy_device *phydev, bool clk_stop_enable)
/* Configure the PHY to stop receiving xMII
* clock while it is signaling LPI.
*/
- int val = phy_read_mmd_indirect(phydev, MDIO_CTRL1,
- MDIO_MMD_PCS);
+ int val = phy_read_mmd(phydev, MDIO_MMD_PCS, MDIO_CTRL1);
if (val < 0)
return val;
val |= MDIO_PCS_CTRL1_CLKSTOP_EN;
- phy_write_mmd_indirect(phydev, MDIO_CTRL1,
- MDIO_MMD_PCS, val);
+ phy_write_mmd(phydev, MDIO_MMD_PCS, MDIO_CTRL1, val);
}
return 0; /* EEE supported */
@@ -1264,7 +1259,7 @@ EXPORT_SYMBOL(phy_init_eee);
*/
int phy_get_eee_err(struct phy_device *phydev)
{
- return phy_read_mmd_indirect(phydev, MDIO_PCS_EEE_WK_ERR, MDIO_MMD_PCS);
+ return phy_read_mmd(phydev, MDIO_MMD_PCS, MDIO_PCS_EEE_WK_ERR);
}
EXPORT_SYMBOL(phy_get_eee_err);
@@ -1281,19 +1276,19 @@ int phy_ethtool_get_eee(struct phy_device *phydev, struct ethtool_eee *data)
int val;
/* Get Supported EEE */
- val = phy_read_mmd_indirect(phydev, MDIO_PCS_EEE_ABLE, MDIO_MMD_PCS);
+ val = phy_read_mmd(phydev, MDIO_MMD_PCS, MDIO_PCS_EEE_ABLE);
if (val < 0)
return val;
data->supported = mmd_eee_cap_to_ethtool_sup_t(val);
/* Get advertisement EEE */
- val = phy_read_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN);
+ val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV);
if (val < 0)
return val;
data->advertised = mmd_eee_adv_to_ethtool_adv_t(val);
/* Get LP advertisement EEE */
- val = phy_read_mmd_indirect(phydev, MDIO_AN_EEE_LPABLE, MDIO_MMD_AN);
+ val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_LPABLE);
if (val < 0)
return val;
data->lp_advertised = mmd_eee_adv_to_ethtool_adv_t(val);
@@ -1316,7 +1311,7 @@ int phy_ethtool_set_eee(struct phy_device *phydev, struct ethtool_eee *data)
/* Mask prohibited EEE modes */
val &= ~phydev->eee_broken_modes;
- phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN, val);
+ phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
return 0;
}
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 92b08383cafa..453b9aca8f24 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1198,7 +1198,7 @@ static int genphy_config_eee_advert(struct phy_device *phydev)
* supported by the phy. If we read 0, EEE is not advertised
* In both case, we don't need to continue
*/
- adv = phy_read_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN);
+ adv = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV);
if (adv <= 0)
return 0;
@@ -1209,7 +1209,7 @@ static int genphy_config_eee_advert(struct phy_device *phydev)
if (old_adv == adv)
return 0;
- phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN, adv);
+ phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV, adv);
return 1;
}
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 5/7] net: phy: convert micrel to new read_mmd/write_mmd driver methods
From: Russell King @ 2017-01-13 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113152059.GR14217@n2100.armlinux.org.uk>
Convert micrel to the new read_mmd/write_mmd driver methods. This
Clause 22 PHY does not support any MMD access method.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/phy/micrel.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 9a77289109b7..8d6432c23a14 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -637,8 +637,7 @@ static int ksz8873mll_config_aneg(struct phy_device *phydev)
* MMD extended PHY registers.
*/
static int
-ksz9021_rd_mmd_phyreg(struct phy_device *phydev, int ptrad, int devnum,
- int regnum)
+ksz9021_rd_mmd_phyreg(struct phy_device *phydev, int devad, u16 regnum)
{
return -1;
}
@@ -646,10 +645,10 @@ ksz9021_rd_mmd_phyreg(struct phy_device *phydev, int ptrad, int devnum,
/* This routine does nothing since the Micrel ksz9021 does not support
* standard IEEE MMD extended PHY registers.
*/
-static void
-ksz9021_wr_mmd_phyreg(struct phy_device *phydev, int ptrad, int devnum,
- int regnum, u32 val)
+static int
+ksz9021_wr_mmd_phyreg(struct phy_device *phydev, int devad, u16 regnum, u16 val)
{
+ return -1;
}
static int kszphy_get_sset_count(struct phy_device *phydev)
@@ -962,8 +961,8 @@ static struct phy_driver ksphy_driver[] = {
.get_stats = kszphy_get_stats,
.suspend = genphy_suspend,
.resume = genphy_resume,
- .read_mmd_indirect = ksz9021_rd_mmd_phyreg,
- .write_mmd_indirect = ksz9021_wr_mmd_phyreg,
+ .read_mmd = ksz9021_rd_mmd_phyreg,
+ .write_mmd = ksz9021_wr_mmd_phyreg,
}, {
.phy_id = PHY_ID_KSZ9031,
.phy_id_mask = MICREL_PHY_ID_MASK,
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 6/7] net: phy: remove the indirect MMD read/write methods
From: Russell King @ 2017-01-13 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113152059.GR14217@n2100.armlinux.org.uk>
Remove the indirect MMD read/write methods which are now no longer
necessary.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/phy/phy-core.c | 119 +++++++++++++--------------------------------
include/linux/phy.h | 18 -------
2 files changed, 35 insertions(+), 102 deletions(-)
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
index b50b3a64cf6a..80795ccd3fab 100644
--- a/drivers/net/phy/phy-core.c
+++ b/drivers/net/phy/phy-core.c
@@ -23,102 +23,41 @@ static inline void mmd_phy_indirect(struct mii_bus *bus, int prtad, int devad,
}
/**
- * phy_read_mmd_indirect - reads data from the MMD registers
- * @phydev: The PHY device bus
- * @prtad: MMD Address
- * @devad: MMD DEVAD
- *
- * Description: it reads data from the MMD registers (clause 22 to access to
- * clause 45) of the specified phy address.
- * To read these register we have:
- * 1) Write reg 13 // DEVAD
- * 2) Write reg 14 // MMD Address
- * 3) Write reg 13 // MMD Data Command for MMD DEVAD
- * 3) Read reg 14 // Read MMD data
- */
-int phy_read_mmd_indirect(struct phy_device *phydev, int prtad, int devad)
-{
- struct phy_driver *phydrv = phydev->drv;
- int addr = phydev->mdio.addr;
- int value = -1;
-
- if (!phydrv->read_mmd_indirect) {
- struct mii_bus *bus = phydev->mdio.bus;
-
- mutex_lock(&bus->mdio_lock);
- mmd_phy_indirect(bus, prtad, devad, addr);
-
- /* Read the content of the MMD's selected register */
- value = bus->read(bus, addr, MII_MMD_DATA);
- mutex_unlock(&bus->mdio_lock);
- } else {
- value = phydrv->read_mmd_indirect(phydev, prtad, devad, addr);
- }
- return value;
-}
-EXPORT_SYMBOL(phy_read_mmd_indirect);
-
-/**
* phy_read_mmd - Convenience function for reading a register
* from an MMD on a given PHY.
* @phydev: The phy_device struct
- * @devad: The MMD to read from
- * @regnum: The register on the MMD to read
+ * @devad: The MMD to read from (0..31)
+ * @regnum: The register on the MMD to read (0..65535)
*
* Same rules as for phy_read();
*/
int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
{
+ int val;
+
if (regnum > (u16)~0 || devad > 32)
return -EINVAL;
- if (phydev->drv->read_mmd)
- return phydev->drv->read_mmd(phydev, devad, regnum);
-
- if (phydev->is_c45) {
+ if (phydev->drv->read_mmd) {
+ val = phydev->drv->read_mmd(phydev, devad, regnum);
+ } else if (phydev->is_c45) {
u32 addr = MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff);
- return mdiobus_read(phydev->mdio.bus, phydev->mdio.addr, addr);
- }
-
- return phy_read_mmd_indirect(phydev, regnum, devad);
-}
-EXPORT_SYMBOL(phy_read_mmd);
-
-/**
- * phy_write_mmd_indirect - writes data to the MMD registers
- * @phydev: The PHY device
- * @prtad: MMD Address
- * @devad: MMD DEVAD
- * @data: data to write in the MMD register
- *
- * Description: Write data from the MMD registers of the specified
- * phy address.
- * To write these register we have:
- * 1) Write reg 13 // DEVAD
- * 2) Write reg 14 // MMD Address
- * 3) Write reg 13 // MMD Data Command for MMD DEVAD
- * 3) Write reg 14 // Write MMD data
- */
-void phy_write_mmd_indirect(struct phy_device *phydev, int prtad,
- int devad, u32 data)
-{
- struct phy_driver *phydrv = phydev->drv;
- int addr = phydev->mdio.addr;
- if (!phydrv->write_mmd_indirect) {
+ val = mdiobus_read(phydev->mdio.bus, phydev->mdio.addr, addr);
+ } else {
struct mii_bus *bus = phydev->mdio.bus;
+ int phy_addr = phydev->mdio.addr;
mutex_lock(&bus->mdio_lock);
- mmd_phy_indirect(bus, prtad, devad, addr);
+ mmd_phy_indirect(bus, regnum, devad, phy_addr);
- /* Write the data into MMD's selected register */
- bus->write(bus, addr, MII_MMD_DATA, data);
+ /* Read the content of the MMD's selected register */
+ val = bus->read(bus, phy_addr, MII_MMD_DATA);
mutex_unlock(&bus->mdio_lock);
- } else {
- phydrv->write_mmd_indirect(phydev, prtad, devad, addr, data);
}
+ return val;
}
-EXPORT_SYMBOL(phy_write_mmd_indirect);
+EXPORT_SYMBOL(phy_read_mmd);
/**
* phy_write_mmd - Convenience function for writing a register
@@ -132,19 +71,31 @@ EXPORT_SYMBOL(phy_write_mmd_indirect);
*/
int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
{
+ int ret;
+
if (regnum > (u16)~0 || devad > 32)
return -EINVAL;
- if (phydev->drv->read_mmd)
- return phydev->drv->write_mmd(phydev, devad, regnum, val);
-
- if (phydev->is_c45) {
+ if (phydev->drv->read_mmd) {
+ ret = phydev->drv->write_mmd(phydev, devad, regnum, val);
+ } else if (phydev->is_c45) {
u32 addr = MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff);
- return mdiobus_write(phydev->mdio.bus, phydev->mdio.addr,
- addr, val);
- }
+ ret = mdiobus_write(phydev->mdio.bus, phydev->mdio.addr,
+ addr, val);
+ } else {
+ struct mii_bus *bus = phydev->mdio.bus;
+ int phy_addr = phydev->mdio.addr;
- return phy_write_mmd_indirect(phydev, regnum, devad, val);
+ mutex_lock(&bus->mdio_lock);
+ mmd_phy_indirect(bus, regnum, devad, phy_addr);
+
+ /* Write the data into MMD's selected register */
+ bus->write(bus, phy_addr, MII_MMD_DATA, val);
+ mutex_unlock(&bus->mdio_lock);
+
+ ret = 0;
+ }
+ return ret;
}
EXPORT_SYMBOL(phy_write_mmd);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 54fa76efb096..ebd1c55f1624 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -607,24 +607,6 @@ struct phy_driver {
int (*write_mmd)(struct phy_device *dev, int devnum, u16 regnum,
u16 val);
- /* A function provided by a phy specific driver to override the
- * the PHY driver framework support for reading a MMD register
- * from the PHY. If not supported, return -1. This function is
- * optional for PHY specific drivers, if not provided then the
- * default MMD read function is used by the PHY framework.
- */
- int (*read_mmd_indirect)(struct phy_device *dev, int ptrad,
- int devnum, int regnum);
-
- /* A function provided by a phy specific driver to override the
- * the PHY driver framework support for writing a MMD register
- * from the PHY. This function is optional for PHY specific drivers,
- * if not provided then the default MMD read function is used by
- * the PHY framework.
- */
- void (*write_mmd_indirect)(struct phy_device *dev, int ptrad,
- int devnum, int regnum, u32 val);
-
/* Get the size and type of the eeprom contained within a plug-in
* module */
int (*module_info)(struct phy_device *dev,
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 7/7] net: phy: clean up mmd_phy_indirect()
From: Russell King @ 2017-01-13 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113152059.GR14217@n2100.armlinux.org.uk>
Make mmd_phy_indirect() use the same terminology as the rest of the
code, making clear what each address is - phy address, devad, and
register number.
While here, remove the "inline" from this static function, leaving
it to the compiler to decide whether to inline this function, and
get rid of unnecessary parens.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/phy/phy-core.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
index 80795ccd3fab..357a4d0d7641 100644
--- a/drivers/net/phy/phy-core.c
+++ b/drivers/net/phy/phy-core.c
@@ -9,17 +9,17 @@
#include <linux/export.h>
#include <linux/phy.h>
-static inline void mmd_phy_indirect(struct mii_bus *bus, int prtad, int devad,
- int addr)
+static void mmd_phy_indirect(struct mii_bus *bus, int phy_addr, int devad,
+ u16 regnum)
{
/* Write the desired MMD Devad */
- bus->write(bus, addr, MII_MMD_CTRL, devad);
+ bus->write(bus, phy_addr, MII_MMD_CTRL, devad);
/* Write the desired MMD register address */
- bus->write(bus, addr, MII_MMD_DATA, prtad);
+ bus->write(bus, phy_addr, MII_MMD_DATA, regnum);
/* Select the Function : DATA with no post increment */
- bus->write(bus, addr, MII_MMD_CTRL, (devad | MII_MMD_CTRL_NOINCR));
+ bus->write(bus, phy_addr, MII_MMD_CTRL, devad | MII_MMD_CTRL_NOINCR);
}
/**
@@ -49,7 +49,7 @@ int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
int phy_addr = phydev->mdio.addr;
mutex_lock(&bus->mdio_lock);
- mmd_phy_indirect(bus, regnum, devad, phy_addr);
+ mmd_phy_indirect(bus, phy_addr, devad, regnum);
/* Read the content of the MMD's selected register */
val = bus->read(bus, phy_addr, MII_MMD_DATA);
@@ -88,7 +88,7 @@ int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
int phy_addr = phydev->mdio.addr;
mutex_lock(&bus->mdio_lock);
- mmd_phy_indirect(bus, regnum, devad, phy_addr);
+ mmd_phy_indirect(bus, phy_addr, devad, regnum);
/* Write the data into MMD's selected register */
bus->write(bus, phy_addr, MII_MMD_DATA, val);
--
2.7.4
^ permalink raw reply related
* [PATCH v2 05/12] Document: dt: binding: imx: update pinctrl doc for imx6sll
From: Linus Walleij @ 2017-01-13 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM3PR04MB530A88C5C0E7C6AD2C59B9E87790@AM3PR04MB530.eurprd04.prod.outlook.com>
On Thu, Jan 12, 2017 at 3:57 AM, Jacky Bai <ping.bai@nxp.com> wrote:
> Another thing is that we can use a pins-tool program developed by NXP to
> generate the pinctrl configuration code that can be used directly in dts. This
> tiny program can avoid pin function conflict. As on i.MX, there are so may pins,
> each pin can be used for up 8 function. Configuring the pins is a time-consuming
> work. This tools is very useful for customer to generate the dts code.
I understand, but every silicon vendor has such a tool, all are different,
proprietary and unfriendly to programmers and open source developers, who
need to understand how the hardware is working without magic tools
and secret data sheets to fix bugs.
For the people working with maintaining the code it is paramount that
DTS files are self-descriptive.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 6/6] arm: dts: mt2701: Add thermal device node.
From: Matthias Brugger @ 2017-01-13 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484296978-18572-7-git-send-email-erin.lo@mediatek.com>
On 13/01/17 09:42, Erin Lo wrote:
> From: Dawei Chien <dawei.chien@mediatek.com>
>
> Add thermal controller device nodes for MT2701.
>
> Signed-off-by: Dawei Chien <dawei.chien@mediatek.com>
> Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> ---
> arch/arm/boot/dts/mt2701.dtsi | 43 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index 3847f70..c43d5f8 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -89,6 +89,36 @@
> clock-output-names = "rtc32k";
> };
>
> + thermal-zones {
> + cpu_thermal: cpu_thermal {
> + polling-delay-passive = <1000>; /* milliseconds */
> + polling-delay = <1000>; /* milliseconds */
> +
> + thermal-sensors = <&thermal 0>;
> + sustainable-power = <1000>;
> +
> + trips {
> + threshold: trip-point at 0 {
> + temperature = <68000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + target: trip-point at 1 {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + cpu_crit: cpu_crit at 0 {
> + temperature = <115000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> + };
> +
> timer {
> compatible = "arm,armv7-timer";
> interrupt-parent = <&gic>;
> @@ -270,6 +300,19 @@
> status = "disabled";
> };
>
> + thermal: thermal at 1100b000 {
> + #thermal-sensor-cells = <0>;
> + compatible = "mediatek,mt2701-thermal";
> + reg = <0 0x1100b000 0 0x1000>;
> + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
> + clock-names = "therm", "auxadc";
> + resets = <&pericfg 0x10>;
should be MT2701_PERI_AUXADC_SW_RST, right?
> + reset-names = "therm";
> + mediatek,auxadc = <&auxadc>;
> + mediatek,apmixedsys = <&apmixedsys>;
> + };
> +
> nandc: nfi at 1100d000 {
> compatible = "mediatek,mt2701-nfc";
> reg = <0 0x1100d000 0 0x1000>;
>
^ permalink raw reply
* [PATCH v2 1/6] arm: dts: mt2701: Add spi device node
From: Matthias Brugger @ 2017-01-13 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484296978-18572-2-git-send-email-erin.lo@mediatek.com>
On 13/01/17 09:42, Erin Lo wrote:
> From: Leilk Liu <leilk.liu@mediatek.com>
>
> Add spi device node for MT2701.
>
> Signed-off-by: Leilk Liu <leilk.liu@mediatek.com>
> Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> ---
> arch/arm/boot/dts/mt2701-evb.dts | 50 ++++++++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/mt2701.dtsi | 39 +++++++++++++++++++++++++++++++
> 2 files changed, 89 insertions(+)
>
Applied to v4.10-next/dts32
> diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
> index 082ca88..879f1eb 100644
> --- a/arch/arm/boot/dts/mt2701-evb.dts
> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> @@ -24,6 +24,56 @@
> };
> };
>
> +&pio {
> + spi_pins_a: spi0 at 0 {
> + pins_spi {
> + pinmux = <MT2701_PIN_53_SPI0_CSN__FUNC_SPI0_CS>,
> + <MT2701_PIN_54_SPI0_CK__FUNC_SPI0_CK>,
> + <MT2701_PIN_55_SPI0_MI__FUNC_SPI0_MI>,
> + <MT2701_PIN_56_SPI0_MO__FUNC_SPI0_MO>;
> + bias-disable;
> + };
> + };
> +
> + spi_pins_b: spi1 at 0 {
> + pins_spi {
> + pinmux = <MT2701_PIN_7_SPI1_CSN__FUNC_SPI1_CS>,
> + <MT2701_PIN_8_SPI1_MI__FUNC_SPI1_MI>,
> + <MT2701_PIN_9_SPI1_MO__FUNC_SPI1_MO>,
> + <MT2701_PIN_199_SPI1_CLK__FUNC_SPI1_CK>;
> + bias-disable;
> + };
> + };
> +
> + spi_pins_c: spi2 at 0 {
> + pins_spi {
> + pinmux = <MT2701_PIN_101_SPI2_CSN__FUNC_SPI2_CS>,
> + <MT2701_PIN_102_SPI2_MI__FUNC_SPI2_MI>,
> + <MT2701_PIN_103_SPI2_MO__FUNC_SPI2_MO>,
> + <MT2701_PIN_104_SPI2_CLK__FUNC_SPI2_CK>;
> + bias-disable;
> + };
> + };
> +};
> +
> +&spi0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi_pins_a>;
> + status = "disabled";
> +};
> +
> +&spi1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi_pins_b>;
> + status = "disabled";
> +};
> +
> +&spi2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi_pins_c>;
> + status = "disabled";
> +};
> +
> &uart0 {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index bdf8954..eb4c6fd 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -227,6 +227,45 @@
> status = "disabled";
> };
>
> + spi0: spi at 1100a000 {
> + compatible = "mediatek,mt2701-spi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0 0x1100a000 0 0x100>;
> + interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
> + <&topckgen CLK_TOP_SPI0_SEL>,
> + <&pericfg CLK_PERI_SPI0>;
> + clock-names = "parent-clk", "sel-clk", "spi-clk";
> + status = "disabled";
> + };
> +
> + spi1: spi at 11016000 {
> + compatible = "mediatek,mt2701-spi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0 0x11016000 0 0x100>;
> + interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
> + <&topckgen CLK_TOP_SPI1_SEL>,
> + <&pericfg CLK_PERI_SPI1>;
> + clock-names = "parent-clk", "sel-clk", "spi-clk";
> + status = "disabled";
> + };
> +
> + spi2: spi at 11017000 {
> + compatible = "mediatek,mt2701-spi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0 0x11017000 0 0x1000>;
> + interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
> + <&topckgen CLK_TOP_SPI2_SEL>,
> + <&pericfg CLK_PERI_SPI2>;
> + clock-names = "parent-clk", "sel-clk", "spi-clk";
> + status = "disabled";
> + };
> +
> mmsys: syscon at 14000000 {
> compatible = "mediatek,mt2701-mmsys", "syscon";
> reg = <0 0x14000000 0 0x1000>;
>
^ permalink raw reply
* [PATCH v2 3/6] arm: dts: mt2701: Add nand device node
From: Matthias Brugger @ 2017-01-13 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484296978-18572-4-git-send-email-erin.lo@mediatek.com>
On 13/01/17 09:42, Erin Lo wrote:
> From: Xiaolei Li <xiaolei.li@mediatek.com>
>
> Add mt2701 nand device node, include nfi and bch ecc.
>
> Signed-off-by: Xiaolei Li <xiaolei.li@mediatek.com>
> Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> ---
> arch/arm/boot/dts/mt2701.dtsi | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
Applied to v4.10-next/dts32
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index 87be52c..1182c43 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -261,6 +261,28 @@
> status = "disabled";
> };
>
> + nandc: nfi at 1100d000 {
> + compatible = "mediatek,mt2701-nfc";
> + reg = <0 0x1100d000 0 0x1000>;
> + interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&pericfg CLK_PERI_NFI>,
> + <&pericfg CLK_PERI_NFI_PAD>;
> + clock-names = "nfi_clk", "pad_clk";
> + status = "disabled";
> + ecc-engine = <&bch>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + bch: ecc at 1100e000 {
> + compatible = "mediatek,mt2701-ecc";
> + reg = <0 0x1100e000 0 0x1000>;
> + interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&pericfg CLK_PERI_NFI_ECC>;
> + clock-names = "nfiecc_clk";
> + status = "disabled";
> + };
> +
> spi1: spi at 11016000 {
> compatible = "mediatek,mt2701-spi";
> #address-cells = <1>;
>
^ permalink raw reply
* [PATCH v2 4/6] arm: dts: mt2701: Add auxadc device node.
From: Matthias Brugger @ 2017-01-13 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484296978-18572-5-git-send-email-erin.lo@mediatek.com>
On 13/01/17 09:42, Erin Lo wrote:
> From: Zhiyong Tao <zhiyong.tao@mediatek.com>
>
> Add auxadc device node for MT2701.
>
> Signed-off-by: Zhiyong Tao <zhiyong.tao@mediatek.com>
> Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> ---
> arch/arm/boot/dts/mt2701-evb.dts | 4 ++++
> arch/arm/boot/dts/mt2701.dtsi | 9 +++++++++
> 2 files changed, 13 insertions(+)
>
Applied to v4.10-next/dts32
> diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
> index 879f1eb..a483798 100644
> --- a/arch/arm/boot/dts/mt2701-evb.dts
> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> @@ -24,6 +24,10 @@
> };
> };
>
> +&auxadc {
> + status = "okay";
> +};
> +
> &pio {
> spi_pins_a: spi0 at 0 {
> pins_spi {
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index 1182c43..4f52019 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -208,6 +208,15 @@
> <0 0x10216000 0 0x2000>;
> };
>
> + auxadc: adc at 11001000 {
> + compatible = "mediatek,mt2701-auxadc";
> + reg = <0 0x11001000 0 0x1000>;
> + clocks = <&pericfg CLK_PERI_AUXADC>;
> + clock-names = "main";
> + #io-channel-cells = <1>;
> + status = "disabled";
> + };
> +
> uart0: serial at 11002000 {
> compatible = "mediatek,mt2701-uart",
> "mediatek,mt6577-uart";
>
^ permalink raw reply
* [PATCH v5] arm64: dts: mt8173: add mmsel clocks for 4K support
From: Matthias Brugger @ 2017-01-13 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGS+omAZvHmSz6bJcvisC1LZgxwbd-HzvYMDrHXzfkY3mZZEsw@mail.gmail.com>
On 12/01/17 05:50, Daniel Kurtz wrote:
> Hi Matthias,
>
> (Trying again to send plain text email)...
>
> On Thu, Aug 4, 2016 at 10:57 AM, Bibby Hsieh <bibby.hsieh@mediatek.com> wrote:
>> To support HDMI 4K resolution, mmsys need clcok
>> mm_sel to be 400MHz.
>>
>> The board .dts file should override the clock rate
>> property with the higher VENCPLL frequency the board
>> supports HDMI 4K resolution.
>>
>> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
>
> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
>
Applied to v4.10-next/dts
Thanks
>
> It looks like this patch was lost. It is actually a prerequisite for
> MTK 4k HDMI support, which already landed in v4.9.
>
> See the email thread entitled:
> [PATCH v5 0/3] MT8173 HDMI 4K support <https://lkml.org/lkml/2016/9/28/893>
>
> Or these three:
>
> 0d2200794f0a drm/mediatek: modify the factor to make the pll_rate set
> in the 1G-2G range
> 968253bd7caa drm/mediatek: enhance the HDMI driving current
> d542b7c473f0 drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable
>
> -Dan
>
>> ---
>> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index 78529e4..c3f32f3 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -690,6 +690,8 @@
>> compatible = "mediatek,mt8173-mmsys", "syscon";
>> reg = <0 0x14000000 0 0x1000>;
>> power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
>> + assigned-clocks = <&topckgen CLK_TOP_MM_SEL>;
>> + assigned-clock-rates = <400000000>;
>> #clock-cells = <1>;
>> };
>>
>> --
>> 1.7.9.5
>>
^ permalink raw reply
* [PATCH 1/3] rtc: stm32: remove __exit annotation on remove callback
From: Arnd Bergmann @ 2017-01-13 15:32 UTC (permalink / raw)
To: linux-arm-kernel
The remove function can be called at runtime for a manual 'unbind'
operation and must not be left out from a built-in driver, as kbuild
complains:
`stm32_rtc_remove' referenced in section `.data.stm32_rtc_driver' of drivers/rtc/rtc-stm32.o: defined in discarded section `.exit.text' of drivers/rtc/rtc-stm32.o
This removes the extraneous annotation.
Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/rtc/rtc-stm32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-stm32.c b/drivers/rtc/rtc-stm32.c
index c4789b5a5d81..3513e052722f 100644
--- a/drivers/rtc/rtc-stm32.c
+++ b/drivers/rtc/rtc-stm32.c
@@ -657,7 +657,7 @@ static int stm32_rtc_probe(struct platform_device *pdev)
return ret;
}
-static int __exit stm32_rtc_remove(struct platform_device *pdev)
+static int stm32_rtc_remove(struct platform_device *pdev)
{
struct stm32_rtc *rtc = platform_get_drvdata(pdev);
unsigned int cr;
--
2.9.0
^ permalink raw reply related
* [PATCH 2/3] rtc: stm32: fix building without CONFIG_OF
From: Arnd Bergmann @ 2017-01-13 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113153311.2611510-1-arnd@arndb.de>
The new driver has a stray #ifdef in it that causes a build error:
drivers/rtc/rtc-stm32.c:718:21: error: 'stm32_rtc_of_match' undeclared here (not in a function); did you mean 'stm32_rtc_pm_ops'?
As the #ifdef serves no purpose here, let's just remove it.
Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/rtc/rtc-stm32.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/rtc/rtc-stm32.c b/drivers/rtc/rtc-stm32.c
index 3513e052722f..8c599f52124c 100644
--- a/drivers/rtc/rtc-stm32.c
+++ b/drivers/rtc/rtc-stm32.c
@@ -490,13 +490,11 @@ static const struct rtc_class_ops stm32_rtc_ops = {
.alarm_irq_enable = stm32_rtc_alarm_irq_enable,
};
-#ifdef CONFIG_OF
static const struct of_device_id stm32_rtc_of_match[] = {
{ .compatible = "st,stm32-rtc" },
{}
};
MODULE_DEVICE_TABLE(of, stm32_rtc_of_match);
-#endif
static int stm32_rtc_init(struct platform_device *pdev,
struct stm32_rtc *rtc)
--
2.9.0
^ permalink raw reply related
* [PATCH 3/3] rtc: stm32: use 32-bit cast for BIT() macro
From: Arnd Bergmann @ 2017-01-13 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113153311.2611510-1-arnd@arndb.de>
Using the ~ operator on a BIT() constant results in a large 'unsigned long'
constant that won't fit into an 'unsigned int' function argument on 64-bit
architectures, resulting in a harmless build warning in x86 allmodconfig:
drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_probe':
drivers/rtc/rtc-stm32.c:651:51: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
regmap_update_bits(rtc->dbp, PWR_CR, PWR_CR_DBP, ~PWR_CR_DBP);
This works around the warning by adding an explict cast to 'u32', but
that is unfortunately a bit ugly and I feel there should be a better
way to do this, possibly with some changes to either the bitops.h
header or the regmap API.
Cc: Mark Brown <broonie@kernel.org>
Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/rtc/rtc-stm32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-stm32.c b/drivers/rtc/rtc-stm32.c
index 8c599f52124c..05d3dc89e55f 100644
--- a/drivers/rtc/rtc-stm32.c
+++ b/drivers/rtc/rtc-stm32.c
@@ -92,7 +92,7 @@
/* STM32_PWR_CR */
#define PWR_CR 0x00
/* STM32_PWR_CR bit field */
-#define PWR_CR_DBP BIT(8)
+#define PWR_CR_DBP (u32)BIT(8)
struct stm32_rtc {
struct rtc_device *rtc_dev;
--
2.9.0
^ 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