Re: DRM DMA Engine
Hi Ilia, Thanks for your answer. On 16-06-2016 13:39, Ilia Mirkin wrote: > On Thu, Jun 16, 2016 at 8:09 AM, Jose Abreu wrote: >> Hi Daniel, >> >> Sorry to bother you again. I promise this is the last time :) >> >> On 15-06-2016 11:15, Daniel Vetter wrote: >>> On Wed, Jun 15, 2016 at 11:48 AM, Jose Abreu >>> wrote: >>>> On 15-06-2016 09:52, Daniel Vetter wrote: >>>>> On Tue, Jun 14, 2016 at 1:19 PM, Jose Abreu >>>>> wrote: >>>>>>> I assume that xilinx VDMA is the only way to feed pixel data into your >>>>>>> display pipeline. Under that assumption: >>>>>>> >>>>>>> drm_plane should map to Xilinx VDMA, and the drm_plane->drm_crtc link >>>>>>> would represent the dma channel. With atomic you can subclass >>>>>>> drm_plane/crtc_state structures to store all the runtime configuration >>>>>>> in >>>>>>> there. >>>>>>> >>>>>>> The actual buffer itsel would be represented by a drm_framebuffer, which >>>>>>> either wraps a shmem gem or a cma gem object. >>>>>>> >>>>>>> If you want to know about the callbacks used by the atomic helpers to >>>>>>> push >>>>>>> out plane updates, look at the hooks drm_atomic_helper_commit_planes() >>>>>>> (and the related functions, see kerneldoc) calls. >>>>>>> >>>>>>> I hope this helps a bit more. >>>>>>> -Daniel >>>>>> Thanks a lot! With your help I was able to implement all the >>>>>> needed logic. Sorry to bother you but I have one more question. >>>>>> Right now I can initialize and configure the vdma correctly but I >>>>>> can only send one frame. I guess when the dma completes >>>>>> transmission I need to ask drm for a new frame, right? Because >>>>>> the commit function starts the vdma correctly but then the dma >>>>>> halts waiting for a new descriptor. >>>>> DRM has a continuous scanout model, i.e. when userspace doesn't give >>>>> you a new frame you're supposed to keep scanning out the current one. >>>>> So you need to rearm your upload code with the same drm_framebuffer if >>>>> userspace hasn't supplied a new one since the last time before the >>>>> vblank period starts. >>>>> >>>>> This is different to v4l, where userspace has to supply each frame >>>>> (and the kernel gets angry when there's not enough frames and signals >>>>> an underrun of the queue). This is because drm is geared at desktops, >>>>> and there it's perfectly normal to show the exact same frame for a >>>>> long time. >>>>> -Daniel >>>> Thanks, I was thinking this was similar to v4l. I am now able to >>>> send multiple frames so it is finally working! I have one little >>>> implementation detail: The controller that I am using supports >>>> deep color mode but I am using FB CMA helpers to create the >>>> framebuffer and I've seen that the supported bpp in these helpers >>>> only goes up to 32, right? Does this means that with these >>>> helpers I can't use deep color? Can I implement this deep color >>>> mode (48bpp) using a custom fb or do I also need custom gem >>>> allocation functions (Right now I am using GEM CMA helpers)? >>> Suprising the cma doesn't take pixel_format into account. If this >>> really doesn't work, pls fix up the cma helpers, not roll your own >>> copypasta ;-) >>> >>> Note that the fbdev emulation itself (maybe that's what threw you off) >>> only supports legacy rgb formats up to 32bits. But native kms can >>> support anything, we just might need to add the DRM_FOURCC codes for >>> that. >>> -Daniel >> So, I ended up using 32bits and everything is working fine! I >> tested using [1] and [2] but now I have kind of a dumb question: >> I want to use the new driver that I created as a secondary output >> of my desktop so that I can play videos using mplayer but I am >> not being able to do this. If I check in my linux settings only >> one display is being detected, although in /dev/dri the two video >> cards are present (the native one and the one I added). Does the >> driver needs something addi
Re: [PATCH 1/3] drm: bridge: add DesignWare HDMI I2S audio support
Hi, On 24-06-2016 03:40, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > Current dw-hdmi is supporting sound via AHB bus, but it has > I2S audio feature too. This patch adds I2S audio support to dw-hdmi. > This HDMI I2S is supported by using ALSA SoC common HDMI encoder > driver. > > Signed-off-by: Kuninori Morimoto > --- > I just tested this patch and everything seems ok. Should I give my tested-by? Best regards, Jose Miguel Abreu
Re: [PATCH 1/3] drm: bridge: add DesignWare HDMI I2S audio support
Hi, On 01-08-2016 05:57, Kuninori Morimoto wrote: > Hi Jose > Cc: Mark, Thierry, Daniel > >>> From: Kuninori Morimoto >>> >>> Current dw-hdmi is supporting sound via AHB bus, but it has >>> I2S audio feature too. This patch adds I2S audio support to dw-hdmi. >>> This HDMI I2S is supported by using ALSA SoC common HDMI encoder >>> driver. >>> >>> Signed-off-by: Kuninori Morimoto >>> --- >>> >> I just tested this patch and everything seems ok. Should I give >> my tested-by? > Thank you for your test. I'm happy if it could have it. > > Mark, Thierry, Daniel > I wonder who can be maintainer for this patch ?? > > Best regards > --- > Kuninori Morimoto Tested-by: Jose Abreu Best regards, Jose Miguel Abreu
Re: [PATCH 3/3 v3] drm: bridge/dw-hdmi: Move edid reading to .detect() callback
Hi Russell, On 04-08-2016 15:31, Russell King - ARM Linux wrote: > On Thu, Aug 04, 2016 at 02:58:00PM +0100, Jose Abreu wrote: >> Hi Russell, >> >> I am not sure if this is a bug in DRM or a bad implementation of >> dw-hdmi. I've seen at least two more drivers that do the edid >> reading at the .detect() callback: nouveau and gma500. This is >> noticeable if while sending video the edid changes like in a >> compliance environment. In the environment that I tested I was >> sending video and swapped an edid that had support for AI packets >> to another one without support and I noticed that although the >> hotplug is generated the edid was not being updated. > The path should be: > > - HPD interrupt > - drm_helper_hpd_irq_event() > - generates uevent to userspace > - output_poll_changed() called > - drm_fb_helper_hotplug_event() > - drm_fb_helper_probe_connector_modes() > - connector->fill_modes() > - drm_helper_probe_single_connector_modes() > - connector_funcs->get_modes() > > Now, if we don't have fbdev emulation, then things won't get much > fruther than output_poll_changed(), and the responsibility for > reading the EDID falls onto userspace. However, as soon as userspace > or the kernel reads the new EDID, that is when any changes in it > should become visible. > > Of course, that should occur in a timely fashion. > Hmm, I am not debugging it right now but I remember that drm_fb_helper_probe_connector_modes() was not being called at the time I set the new EDID but only after I stopped sending video (I was using modetest). Best regards, Jose Miguel Abreu
Re: [PATCH 2/3 v3] drm: bridge/dw-hdmi: Enable ISCR1, ISCR2 and ACP packets
Hi Russell,
On 04-08-2016 16:32, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 11:44:50AM +0100, Jose Abreu wrote:
>> Currently ISCR and ACP packets are not being sent causing
>> HDMI compliance tests like CTS 7-19 HDMI 1.4b to fail.
> Hmm. Reading the HDMI specifications (v1.3, being the publically
> available one), the specification does _not_ say that a source _must_
> transmit ISRC and ACP packets if Supports_AI is set.
>
> What it does say is that:
> * a sink shall set Supports_AI if it supports at least one function
> which uses ISRC or ACP packets, and it shall accept such packets.
> * a source shall not transmit ISRC or ACP packets to a sink that
> has Supports_AI=0.
>
> I don't see anything that mandates the transmission of ISRC and ACP
> packets when Supports_AI is set.
>
> Moreover, transmission of wrong ISRC information probably goes against
> the HDMI spec section 8.8, which requires specific ISRC status values
> in HB1 - I don't see how that _could_ be handled, as the kernel has no
> knowledge about the EAN of the audio content being played, nor when a
> track starts or finishes.
>
> Please clarify.
You are correct. I ran the test again and indeed it is not
failing but it is skipped. Sorry for the confusion. Anyway, with
this patch the test that verifies the ISRC packets succeeds so I
think it would be a nice addition.
>
>> +/* Set ISCR1, ISCR2, and ACP packets to automatic scheduling */
>> +if (hdmi->sink_supports_ai) {
>> +dev_dbg(hdmi->dev, "sink supports AI packets\n");
>> +hdmi_writeb(hdmi, 0x06, HDMI_FC_ISCR1_0);
>> +hdmi_writeb(hdmi, 0x03, HDMI_FC_DATAUTO0);
>> +hdmi_writeb(hdmi, 0x01, HDMI_FC_DATAUTO1);
>> +hdmi_writeb(hdmi, 0x11, HDMI_FC_DATAUTO2);
> So what data gets sent in these packets - I guess whatever random data
> happens to be in the HDMI_FC_ACP* and HDMI_FC_ISCR1_* registers at the
> time the sending is enabled. I don't think that's particularly a good
> idea.
It is not random as the registers defaults to zero per databook.
It is sending an empty packet.
>> @@ -1474,8 +1490,13 @@ static int dw_hdmi_connector_get_modes(struct
>> drm_connector *connector)
>> /* Store the ELD */
>> drm_edid_to_eld(connector, edid);
>> kfree(edid);
>> +
>> +hdmi->sink_supports_ai = connector->eld[5] & (0x1 << 1);
> We have a definition for this bit - DRM_ELD_SUPPORTS_AI.
>
Thanks. Will change in next version if you agree with this
addition. If not I will drop the patch.
Best regards,
Jose Miguel Abreu
Re: [PATCH 3/3 v3] drm: bridge/dw-hdmi: Move edid reading to .detect() callback
Hi Russell, On 04-08-2016 16:04, Russell King - ARM Linux wrote: > On Thu, Aug 04, 2016 at 03:57:21PM +0100, Jose Abreu wrote: >> Hmm, I am not debugging it right now but I remember that >> drm_fb_helper_probe_connector_modes() was not being called at the >> time I set the new EDID but only after I stopped sending video (I >> was using modetest). > Please investigate - I'd prefer that your patch does not get applied > until we really know what's going on here. > > Hmm, if you're using modetest, then userspace is setting a mode, and > userspace is in control of the DRM device - that's probably the reason > why you're not seeing anything happening - modetest probably doesn't > know anything about hotplug events, and so doesn't read the modes. > > Have you tried with the framebuffer console and DRM fbdev emulation > enabled, without using modetest? > So, I didn't use framebuffer console but used X instead and it is working as it should. I think we can drop this patch. I am now making interoperability with DVI and I am facing the following scenario: - I start the driver - An EDID is sent which tells the driver that HDMI is NOT supported; - The driver configures itself to a DVI mode; Until this point everything is working as it should. But: - Now I send an EDID which tells the driver that HDMI is supported; - As the EDID has the same preferred mode the user will not reconfigure the mode and there will be no change to HDMI mode. The missing change to HDMI mode will cause the test to fail. The workaround that I am using is to reconfigure to another video mode and then configure to the preferred one but I think this could be fixed in the driver, right? Best regards, Jose Miguel Abreu
Re: [PATCH 3/3 v3] drm: bridge/dw-hdmi: Move edid reading to .detect() callback
Hi,
On 05-08-2016 09:13, Chris Wilson wrote:
> On Fri, Aug 05, 2016 at 10:06:08AM +0200, Daniel Vetter wrote:
>> On Fri, Aug 05, 2016 at 12:01:25AM +0100, Russell King - ARM Linux wrote:
>>> On Thu, Aug 04, 2016 at 06:13:18PM +0100, Jose Abreu wrote:
>>>> Hi Russell,
>>>>
>>>> So, I didn't use framebuffer console but used X instead and it is
>>>> working as it should. I think we can drop this patch. I am now
>>>> making interoperability with DVI and I am facing the following
>>>> scenario:
>>>> - I start the driver
>>>> - An EDID is sent which tells the driver that HDMI is NOT
>>>> supported;
>>>> - The driver configures itself to a DVI mode;
>>>>
>>>> Until this point everything is working as it should. But:
>>>>
>>>> - Now I send an EDID which tells the driver that HDMI is
>>>> supported;
>>>> - As the EDID has the same preferred mode the user will not
>>>> reconfigure the mode and there will be no change to HDMI mode.
>>> The EDID should still be read, but as you say, userspace doesn't take
>>> any action because it sees that the mode parameters are still the same,
>>> as you have identified.
>>>
>>>> The missing change to HDMI mode will cause the test to fail. The
>>>> workaround that I am using is to reconfigure to another video
>>>> mode and then configure to the preferred one but I think this
>>>> could be fixed in the driver, right?
>>> This one is extremely awkward - to fix it, we would need to check to
>>> see whether we reconfigure the hardware each time we read the EDID,
>>> and I don't think that's a particularly nice thing to do.
>>>
>>> I'd like to hear what other DRM developers think about this issue.
>> I pondored whether we should have a counter on each connector for probe
>> state, which helpers would increment whenever something changes, like:
>> - connector_status (as tracked by probe helpers)
>> - anything in the edid changes (when setting it
>> drm_mode_connector_update_edid_property)
>> - other changes (like sink state changes in dpcd or whatever)
>>
>> That way userspace would be able to reliably spot such changes and do a
>> new modeset.
> Yes, please. I have had similar wishes for state changes and overall
> modeset counters.
> -Chris
>
What about this: Assuming that the modes probed by EDID have the
picture aspect ratio field set we can check for one of this
probed modes when receiving a mode from userspace and then if the
modes match (except from the picture aspect field, which is not
set by userspace) then we can use the picture aspect value of the
probed mode. I am using something like this in my modeset callback:
/* 'mode' comes from userspace, 'pmode' comes from EDID */
if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_NONE) {
struct drm_display_mode *pmode;
list_for_each_entry(pmode, &connector.modes, head) {
if (drm_mode_equal(pmode, mode))
mode->picture_aspect_ratio =
pmode->picture_aspect_ratio;
}
}
Of course if the EDID has for example two exactly equal modes
that only differ in the picture aspect ratio then this will not
work unless user passes the picture aspect when setting the mode.
Best regards,
Jose Miguel Abreu
Re: [PATCH v3 4/4] dt-bindings: media: Document Synopsys Designware HDMI RX
Hi Sylwester,
On 19-06-2017 22:18, Sylwester Nawrocki wrote:
> On 06/19/2017 11:01 AM, Jose Abreu wrote:
>> Using fixed-clock was already in my todo list. Regarding phy I
>> need to pass pdata so that the callbacks between controller and
>> phy are established. I also need to make sure that phy driver
>> will be loaded by the controller driver. Hmm, and also address of
>> the phy on th JTAG bus is fed to the controller driver not to the
>> phy driver. Maybe leave the property as is (the
>> "snps,hdmi-phy-jtag-addr") or parse it from the phy node?
> I think the RX controller can parse it's child phy node to retrieve JTAG
> address from the reg property. That seems better than creating custom
> property for device address on the bus.
Ok, will do that.
>
> Does the PHY support any other type of control bus, e.g. I2C or SPI?
It supports I2C but its all done by controller regbank.
>
>> I also need to pass pdata to the controller driver (the callbacks
>> for 5v handling) which are agnostic of the controller. These
> Is this about detecting +5V coming from the HDMI connector? Or some
> other voltage supply?
Yes, 5v signal from HDMI source.
>
>> reasons prevented me from adding compatible strings to both
>> drivers and just use a wrapper driver instead. This way i do
> If you add struct of_device_id instance to your module and define
> MODULE_DEVICE_ALIAS(of, ...) there, it will allow the module to be loaded
> when device with matching compatible string is created in the kernel.
> User space is notified with uevent about device creation.
Hmm, I used another approach. I have a list of supported phys in
the controller driver and the corresponding driver name, then I
just match the node, get the driver name and do a request module
the of_platform_populate. Maybe its not the best option?
>
>> "modprobe wrapper_driver" and I get all the drivers loaded via
>> request_module(). Still, I like your approach much better. I saw
>> that I can pass pdata using of_platform_populate, could you
>> please confirm if I can still maintain this architecture (i.e.
>> prevent modules from loading until I get all the chain setup)?
> You could try to pass platform data this way, that should work. But
> I doubt it's the right directions, I would rather see things done
> in the V4L2 layer.
But this doesn't exist right? We would need something similar to
v4l2_i2c_new_subdev_board() but for platform devices.
>
>> Following your approach I could get something like this:
>>
>> hdmi_system@ {
>> compatible = "snps,dw-hdmi-rx-wrapper";
> This would need to refer to some hardware block, we should avoid virtual
> device nodes in DT.
By wrapper I mean the SoC, i.e. the whole integration of the
controller + phy + EDID + 5v + ...
>
>> reg = <0x 0x>;
>> interrupts = <3>;
>> #address-cells = <1>;
>> #size-cells = <1>;
> You would need also an (empty) 'ranges' property here.
Yes, I already added it here locally.
>
>> hdmi_controller@0 {
>> compatible = "snps,dw-hdmi-rx-controller";
>> reg = <0x0 0x1>;
>> interrupts = <1>;
>> edid-phandle = <&hdmi_system>;
>> clocks = <&refclk>;
>> clock-names = "ref-clk";
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> hdmi_phy@f3 {
>> compatible = "snps,dw-hdmi-phy-e405";
>> reg = <0xf3>;
>> clocks = <&cfgclk>;
>> clock-names = "cfg-clk";
>> }
>> }
>> };
>>
>> And then snps,dw-hdmi-rx-wrapper would call of_platform_populate
>> for controller which would instead call of_platform_populate for
>> phy. Is this possible, and maintainable? Isn't the controller
>> driver get auto loaded because of the compatible string match?
> As I mentioned above, auto loading should work if you have instance
> of MODULE_DEVICE_TABLE() defined in the module, but the module might
> not be available immediately after creating devices with
> of_platform_populate(). You may want to have a look at the v4l2-async
> API (drivers/media/v4l2-core/v4l2-async.c). It allows one driver
> to register a notifier for its sub-devices. And the parent driver
> can complete initialization when it gets all its v4l2 subdevs
> registered.
>
> But I'm not sure about calls from the PHY back to the RX controller,
> possibly v4l2_set_subdev_hostdata()/v4l2_get_subdev_hostdata
Re: [PATCH v3 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver
HI Sylwester,
On 19-06-2017 23:10, Sylwester Nawrocki wrote:
> On 06/19/2017 11:33 AM, Jose Abreu wrote:
>> On 18-06-2017 19:04, Sylwester Nawrocki wrote:
>>> On 06/16/2017 06:38 PM, Jose Abreu wrote:
>>>> This is an initial submission for the Synopsys Designware HDMI RX
>>>> Controller Driver. This driver interacts with a phy driver so that
>>>> a communication between them is created and a video pipeline is
>>>> configured.
>>>>
>>>> The controller + phy pipeline can then be integrated into a fully
>>>> featured system that can be able to receive video up to 4k@60Hz
>>>> with deep color 48bit RGB, depending on the platform. Although,
>>>> this initial version does not yet handle deep color modes.
>>>> Signed-off-by: Jose Abreu
>>>>
>>>> +static int dw_hdmi_phy_init(struct dw_hdmi_dev *dw_dev)
>>>> +{
>>>> + request_module(pdevinfo.name);
>>>> +
>>>> + dw_dev->phy_pdev = platform_device_register_full(&pdevinfo);
>>>> + if (IS_ERR(dw_dev->phy_pdev)) {
>>>> + dev_err(dw_dev->dev, "failed to register phy device\n");
>>>> + return PTR_ERR(dw_dev->phy_pdev);
>>>> + }
>>>> +
>>>> + if (!dw_dev->phy_pdev->dev.driver) {
>>>> + dev_err(dw_dev->dev, "failed to initialize phy driver\n");
>>>> + goto err;
>>>> + }
>>> I think this is not safe because there is nothing preventing unbinding
>>> or unloading the driver at this point.
>>>
>>>> + if (!try_module_get(dw_dev->phy_pdev->dev.driver->owner)) {
>>> So dw_dev->phy_pdev->dev.driver may be already NULL here.
>> How can I make sure it wont be NULL? Because I've seen other
>> media drivers do this and I don't think they do any kind of
>> locking, but they do this mainly for I2C subdevs.
> You could do device_lock(dev)/device_unlock(dev) to avoid possible races.
> And setting 'suppress_bind_attrs' field in the sub-device drivers would
> disable sysfs unbind attributes, so sub-device driver wouldn't get unbound
> unexpectedly trough sysfs.
Hmm, ok. I changed this, now I'm using driver_find() +
driver_for_each_device(). Its working but I'm starting to think
about whether this should go into v4l2 core because I've seen
other drivers also do this.
>
>>>> + dev_err(dw_dev->dev, "failed to get phy module\n");
>>>> + goto err;
>>>> + }
>>>> +
>>>> + dw_dev->phy_sd = dev_get_drvdata(&dw_dev->phy_pdev->dev);
>>>> + if (!dw_dev->phy_sd) {
>>>> + dev_err(dw_dev->dev, "failed to get phy subdev\n");
>>>> + goto err_put;
>>>> + }
>>>> +
>>>> + if (v4l2_device_register_subdev(&dw_dev->v4l2_dev, dw_dev->phy_sd)) {
>>>> + dev_err(dw_dev->dev, "failed to register phy subdev\n");
>>>> + goto err_put;
>>>> + }
>>> I'd suggest usign v4l2-async API, so we use a common pattern for sub-device
>>> registration. And with recent change [1] you could handle this PHY subdev
>>> in a standard way. That might be more complicated than it is now but should
>>> make any future platform integration easier.
>> So I will instantiate phy driver and then wait for phy driver to
>> register into v4l2 core?
> Yes, for instance the RX controller driver registers a notifier, instantiates
> the child PHY device and then waits until the PHY driver completes
> initialization.
>
>>>> + module_put(dw_dev->phy_pdev->dev.driver->owner);
>>>> + return 0;
>>>> +
>>>> +err_put:
>>>> + module_put(dw_dev->phy_pdev->dev.driver->owner);
>>>> +err:
>>>> + platform_device_unregister(dw_dev->phy_pdev);
>>>> + return -EINVAL;
>>>> +}
>>>> +static int dw_hdmi_power_on(struct dw_hdmi_dev *dw_dev, u32 input)
>>>> +{
>>>> + struct dw_hdmi_work_data *data;
>>>> + unsigned long flags;
>>>> +
>>>> + data = devm_kzalloc(dw_dev->dev, sizeof(*data), GFP_KERNEL);
>>> Why use devm_{kzalloc, kfree} when dw_hdmi_power_on() is not only called
>>> in the device's probe() callback, but in other places, including interrupt
>>> handler? devm_* API is normally used when life time of a resource is more
>>>
[PATCH v4 3/4] MAINTAINERS: Add entry for Synopsys Designware HDMI drivers
Add a entry for Synopsys Designware HDMI Receivers drivers and phys. Signed-off-by: Jose Abreu Cc: Carlos Palminha --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c4be6d4..7ebc6dd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11354,6 +11354,13 @@ L: net...@vger.kernel.org S: Supported F: drivers/net/ethernet/synopsys/ +SYNOPSYS DESIGNWARE HDMI RECEIVERS AND PHY DRIVERS +M: Jose Abreu +L: linux-me...@vger.kernel.org +S: Maintained +F: drivers/media/platform/dwc/* +F: include/media/dwc/* + SYNOPSYS DESIGNWARE I2C DRIVER M: Jarkko Nikula R: Andy Shevchenko -- 1.9.1
[PATCH v4 4/4] dt-bindings: media: Document Synopsys Designware HDMI RX
Document the bindings for the Synopsys Designware HDMI RX.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Rob Herring
Cc: Mark Rutland
Cc: Mauro Carvalho Chehab
Cc: Hans Verkuil
Cc: Sylwester Nawrocki
Changes from v3:
- Document the new DT bindings suggested by Sylwester
Changes from v2:
- Document edid-phandle property
---
.../devicetree/bindings/media/snps,dw-hdmi-rx.txt | 70 ++
1 file changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
new file mode 100644
index 000..efb0ac3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
@@ -0,0 +1,70 @@
+Synopsys DesignWare HDMI RX Decoder
+===
+
+This document defines device tree properties for the Synopsys DesignWare HDMI
+RX Decoder (DWC HDMI RX). It doesn't constitute a device tree binding
+specification by itself but is meant to be referenced by platform-specific
+device tree bindings.
+
+When referenced from platform device tree bindings the properties defined in
+this document are defined as follows.
+
+- compatible: Shall be "snps,dw-hdmi-rx".
+
+- reg: Memory mapped base address and length of the DWC HDMI RX registers.
+
+- interrupts: Reference to the DWC HDMI RX interrupt and 5v sense interrupt.
+
+- clocks: Phandle to the config clock block.
+
+- clock-names: Shall be "cfg-clk".
+
+- edid-phandle: phandle to the EDID handler block.
+
+- #address-cells: Shall be 1.
+
+- #size-cells: Shall be 0.
+
+You also have to create a subnode for phy driver. Phy properties are as
follows.
+
+- compatible: Shall be "snps,dw-hdmi-phy-e405".
+
+- reg: Shall be JTAG address of phy.
+
+- clocks: Phandle for cfg clock.
+
+- clock-names:Shall be "cfg-clk".
+
+A sample binding is now provided. The compatible string is for a SoC which has
+has a Synopsys Designware HDMI RX decoder inside.
+
+Example:
+
+dw_hdmi_soc: dw-hdmi-soc@0 {
+ compatible = "snps,dw-hdmi-soc";
+ reg = <0x11c00 0x1000>; /* EDIDs */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dw_hdmi_rx@0 {
+ compatible = "snps,dw-hdmi-rx";
+ reg = <0x0 0x1>;
+ interrupts = <1 2>;
+ edid-phandle = <&dw_hdmi_soc>;
+
+ clocks = <&dw_hdmi_refclk>;
+ clock-names = "cfg-clk";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dw_hdmi_phy_e405@fc {
+ compatible = "snps,dw-hdmi-phy-e405";
+ reg = <0xfc>;
+
+ clocks = <&dw_hdmi_refclk>;
+ clock-names = "cfg-clk";
+ };
+ };
+};
--
1.9.1
[PATCH v4 0/4] Synopsys Designware HDMI Video Capture Controller + PHY
The Synopsys Designware HDMI RX controller is an HDMI receiver controller that is responsible to process digital data that comes from a phy. The final result is a stream of raw video data that can then be connected to a video DMA, for example, and transfered into RAM so that it can be displayed. The controller + phy available in this series natively support all HDMI 1.4 and HDMI 2.0 modes, including deep color. Although, the driver is quite in its initial stage and unfortunatelly only non deep color modes are supported. Also, audio is not yet supported in the driver (the controller has several audio output interfaces). Version 4 addresses review comments from Sylwester Nawrocki that were mainly regarding the phy initialization and bindings in the DT. We switched to V4L2 async API so that we don't have to wait for phy to be initialized. This series was tested in a FPGA platform. Jose Abreu (4): [media] platform: Add Synopsys Designware HDMI RX PHY e405 Driver [media] platform: Add Synopsys Designware HDMI RX Controller Driver MAINTAINERS: Add entry for Synopsys Designware HDMI drivers dt-bindings: media: Document Synopsys Designware HDMI RX Cc: Carlos Palminha Cc: Mauro Carvalho Chehab Cc: Hans Verkuil Cc: Rob Herring Cc: Mark Rutland Cc: Sylwester Nawrocki .../devicetree/bindings/media/snps,dw-hdmi-rx.txt | 70 + MAINTAINERS|7 + drivers/media/platform/Kconfig |2 + drivers/media/platform/Makefile|2 + drivers/media/platform/dwc/Kconfig | 23 + drivers/media/platform/dwc/Makefile|2 + drivers/media/platform/dwc/dw-hdmi-phy-e405.c | 832 + drivers/media/platform/dwc/dw-hdmi-phy-e405.h | 63 + drivers/media/platform/dwc/dw-hdmi-rx.c| 1862 drivers/media/platform/dwc/dw-hdmi-rx.h| 441 + include/media/dwc/dw-hdmi-phy-pdata.h | 128 ++ include/media/dwc/dw-hdmi-rx-pdata.h | 97 + 12 files changed, 3529 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt create mode 100644 drivers/media/platform/dwc/Kconfig create mode 100644 drivers/media/platform/dwc/Makefile create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.c create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.h create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h create mode 100644 include/media/dwc/dw-hdmi-phy-pdata.h create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h -- 1.9.1
[PATCH v4 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver
This is an initial submission for the Synopsys Designware HDMI RX Controller Driver. This driver interacts with a phy driver so that a communication between them is created and a video pipeline is configured. The controller + phy pipeline can then be integrated into a fully featured system that can be able to receive video up to 4k@60Hz with deep color 48bit RGB, depending on the platform. Although, this initial version does not yet handle deep color modes. This driver was implemented as a standard V4L2 subdevice and its main features are: - Internal state machine that reconfigures phy until the video is not stable - JTAG communication with phy - Inter-module communication with phy driver - Debug write/read ioctls Some notes: - RX sense controller (cable connection/disconnection) must be handled by the platform wrapper as this is not integrated into the controller RTL - The same goes for EDID ROM's - ZCAL calibration is needed only in FPGA platforms, in ASIC this is not needed - The state machine is not an ideal solution as it creates a kthread but it is needed because some sources might not be very stable at sending the video (i.e. we must react accordingly). Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: Mauro Carvalho Chehab Cc: Hans Verkuil Cc: Sylwester Nawrocki Changes from v3: - Use v4l2 async API (Sylwester) - Do not block waiting for phy - Do not use busy waiting delays (Sylwester) - Simplify dw_hdmi_power_on (Sylwester) - Use clock API (Sylwester) - Use compatible string (Sylwester) - Minor fixes (Sylwester) Changes from v2: - Address review comments from Hans regarding CEC - Use CEC notifier - Enable SCDC Changes from v1: - Add support for CEC - Correct typo errors - Correctly detect interlaced video modes - Correct VIC parsing Changes from RFC: - Add support for HDCP 1.4 - Fixup HDMI_VIC not being parsed (Hans) - Send source change signal when powering off (Hans) - Add a "wait stable delay" - Detect interlaced video modes (Hans) - Restrain g/s_register from reading/writing to HDCP regs (Hans) --- drivers/media/platform/dwc/Kconfig | 15 + drivers/media/platform/dwc/Makefile |1 + drivers/media/platform/dwc/dw-hdmi-rx.c | 1862 +++ drivers/media/platform/dwc/dw-hdmi-rx.h | 441 include/media/dwc/dw-hdmi-rx-pdata.h| 97 ++ 5 files changed, 2416 insertions(+) create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h diff --git a/drivers/media/platform/dwc/Kconfig b/drivers/media/platform/dwc/Kconfig index 361d38d..3ddccde 100644 --- a/drivers/media/platform/dwc/Kconfig +++ b/drivers/media/platform/dwc/Kconfig @@ -6,3 +6,18 @@ config VIDEO_DWC_HDMI_PHY_E405 To compile this driver as a module, choose M here. The module will be called dw-hdmi-phy-e405. + +config VIDEO_DWC_HDMI_RX + tristate "Synopsys Designware HDMI Receiver driver" + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API + help + Support for Synopsys Designware HDMI RX controller. + + To compile this driver as a module, choose M here. The module + will be called dw-hdmi-rx. + +config VIDEO_DWC_HDMI_RX_CEC + bool + depends on VIDEO_DWC_HDMI_RX + select CEC_CORE + select CEC_NOTIFIER diff --git a/drivers/media/platform/dwc/Makefile b/drivers/media/platform/dwc/Makefile index fc3b62c..cd04ca9 100644 --- a/drivers/media/platform/dwc/Makefile +++ b/drivers/media/platform/dwc/Makefile @@ -1 +1,2 @@ obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o +obj-$(CONFIG_VIDEO_DWC_HDMI_RX) += dw-hdmi-rx.o diff --git a/drivers/media/platform/dwc/dw-hdmi-rx.c b/drivers/media/platform/dwc/dw-hdmi-rx.c new file mode 100644 index 000..22ee51d --- /dev/null +++ b/drivers/media/platform/dwc/dw-hdmi-rx.c @@ -0,0 +1,1862 @@ +/* + * Synopsys Designware HDMI Receiver controller driver + * + * This Synopsys dw-hdmi-rx software and associated documentation + * (hereinafter the "Software") is an unsupported proprietary work of + * Synopsys, Inc. unless otherwise expressly agreed to in writing between + * Synopsys and you. The Software IS NOT an item of Licensed Software or a + * Licensed Product under any End User Software License Agreement or + * Agreement for Licensed Products with Synopsys or any supplement thereto. + * Synopsys is a registered trademark of Synopsys, Inc. Other names included + * in the SOFTWARE may be the trademarks of their respective owners. + * + * The contents of this file are dual-licensed; you may select either version 2 + * of th
[PATCH v4 1/4] [media] platform: Add Synopsys Designware HDMI RX PHY e405 Driver
This adds support for the Synopsys Designware HDMI RX PHY e405. This phy receives and decodes HDMI video that is delivered to a controller. Main features included in this driver are: - Equalizer algorithm that chooses the phy best settings according to the detected HDMI cable characteristics. - Support for scrambling - Support for HDMI 2.0 modes up to 6G (HDMI 4k@60Hz). The driver was implemented as a standalone V4L2 subdevice and the phy interface with the controller was implemented using V4L2 ioctls. I do not know if this is the best option but it is not possible to use the existing API functions directly as we need specific functions that will be called by the controller at specific configuration stages. There is also a bidirectional communication between controller and phy: The phy must provide functions that the controller will call (i.e. configuration functions) and the controller must provide read/write callbacks, as well as other specific functions. Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: Mauro Carvalho Chehab Cc: Hans Verkuil Cc: Sylwester Nawrocki Changes from v3: - Use v4l2 async API (Sylwester) - Use clock API (Sylwester) - Add compatible string (Sylwester) Changes from RFC: - Remove a bunch of functions that can be collapsed into a single config() function - Add comments for the callbacks and structures (Hans) --- drivers/media/platform/Kconfig| 2 + drivers/media/platform/Makefile | 2 + drivers/media/platform/dwc/Kconfig| 8 + drivers/media/platform/dwc/Makefile | 1 + drivers/media/platform/dwc/dw-hdmi-phy-e405.c | 832 ++ drivers/media/platform/dwc/dw-hdmi-phy-e405.h | 63 ++ include/media/dwc/dw-hdmi-phy-pdata.h | 128 7 files changed, 1036 insertions(+) create mode 100644 drivers/media/platform/dwc/Kconfig create mode 100644 drivers/media/platform/dwc/Makefile create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.c create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.h create mode 100644 include/media/dwc/dw-hdmi-phy-pdata.h diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 1313cd5..47d4a50 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -33,6 +33,8 @@ source "drivers/media/platform/omap/Kconfig" source "drivers/media/platform/blackfin/Kconfig" +source "drivers/media/platform/dwc/Kconfig" + config VIDEO_SH_VOU tristate "SuperH VOU video output driver" depends on MEDIA_CAMERA_SUPPORT diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index 9beadc7..e6a55fb 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -86,3 +86,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_MDP) += mtk-mdp/ obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk-jpeg/ obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/ + +obj-y += dwc/ diff --git a/drivers/media/platform/dwc/Kconfig b/drivers/media/platform/dwc/Kconfig new file mode 100644 index 000..361d38d --- /dev/null +++ b/drivers/media/platform/dwc/Kconfig @@ -0,0 +1,8 @@ +config VIDEO_DWC_HDMI_PHY_E405 + tristate "Synopsys Designware HDMI RX PHY e405 driver" + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API + help + Support for Synopsys Designware HDMI RX PHY. Version is e405. + + To compile this driver as a module, choose M here. The module + will be called dw-hdmi-phy-e405. diff --git a/drivers/media/platform/dwc/Makefile b/drivers/media/platform/dwc/Makefile new file mode 100644 index 000..fc3b62c --- /dev/null +++ b/drivers/media/platform/dwc/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o diff --git a/drivers/media/platform/dwc/dw-hdmi-phy-e405.c b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c new file mode 100644 index 000..d8856f6 --- /dev/null +++ b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c @@ -0,0 +1,832 @@ +/* + * Synopsys Designware HDMI PHY E405 driver + * + * This Synopsys dw-phy-e405 software and associated documentation + * (hereinafter the "Software") is an unsupported proprietary work of + * Synopsys, Inc. unless otherwise expressly agreed to in writing between + * Synopsys and you. The Software IS NOT an item of Licensed Software or a + * Licensed Product under any End User Software License Agreement or + * Agreement for Licensed Products with Synopsys or any supplement thereto. + * Synopsys is a registered trademark of Synopsys, Inc. Other names included + * in the SOFTWARE may be the trademarks of their respective owners. + * + * The contents of this file are dual-licensed; you may select either version 2 + * of the GNU General Public License (“GPL”) or the MIT license (“MIT”). + * + * Copyright (c) 2017 Synopsys,
Re: [PATCH v5 05/10] drm: arcpgu: Use crtc->mode_valid() callback
Hi Daniel, Alexey,
On 25-05-2017 15:19, Jose Abreu wrote:
> Now that we have a callback to check if crtc supports a given mode
> we can use it in arcpgu so that we restrict the number of probbed
> modes to the ones we can actually display.
>
> This is specially useful because arcpgu crtc is responsible to set
> a clock value in the commit() stage but unfortunatelly this clock
> does not support all the needed ranges.
>
> Also, remove the atomic_check() callback as mode_valid() callback
> will be called before.
>
> Signed-off-by: Jose Abreu
> Reviewed-by: Alexey Brodkin
@Daniel: I know that arcpgu is not under drm-misc but could you
apply this into drm-misc-next? Alexey (the arcpgu maintainer)
already gave the reviewed-by and this is also "Reviewed-by: Neil
Armstrong ". It was also tested-by: me.
@Alexey: Is this ok for you?
I need this because I have a pending patch for accepting clock
variations instead of always failing when clk_round_rate() does
not return the expected rate.
Best regards,
Jose Miguel Abreu
> Cc: Carlos Palminha
> Cc: Alexey Brodkin
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: Laurent Pinchart
>
> Changes v4->v5:
> - Change commit message to "arcpgu" (Alexey)
> Changes v3->v4:
> - Do not use aux function (Laurent)
>
> ---
> drivers/gpu/drm/arc/arcpgu_crtc.c | 29 ++---
> 1 file changed, 14 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
> b/drivers/gpu/drm/arc/arcpgu_crtc.c
> index ad9a959..99fbdae 100644
> --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> @@ -64,6 +64,19 @@ static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> };
>
> +enum drm_mode_status arc_pgu_crtc_mode_valid(struct drm_crtc *crtc,
> + const struct drm_display_mode
> *mode)
> +{
> + struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
> + long rate, clk_rate = mode->clock * 1000;
> +
> + rate = clk_round_rate(arcpgu->clk, clk_rate);
> + if (rate != clk_rate)
> + return MODE_NOCLOCK;
> +
> + return MODE_OK;
> +}
> +
> static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc *crtc)
> {
> struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
> @@ -129,20 +142,6 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
> ~ARCPGU_CTRL_ENABLE_MASK);
> }
>
> -static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
> - struct drm_crtc_state *state)
> -{
> - struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
> - struct drm_display_mode *mode = &state->adjusted_mode;
> - long rate, clk_rate = mode->clock * 1000;
> -
> - rate = clk_round_rate(arcpgu->clk, clk_rate);
> - if (rate != clk_rate)
> - return -EINVAL;
> -
> - return 0;
> -}
> -
> static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
> struct drm_crtc_state *state)
> {
> @@ -158,6 +157,7 @@ static void arc_pgu_crtc_atomic_begin(struct drm_crtc
> *crtc,
> }
>
> static const struct drm_crtc_helper_funcs arc_pgu_crtc_helper_funcs = {
> + .mode_valid = arc_pgu_crtc_mode_valid,
> .mode_set = drm_helper_crtc_mode_set,
> .mode_set_base = drm_helper_crtc_mode_set_base,
> .mode_set_nofb = arc_pgu_crtc_mode_set_nofb,
> @@ -165,7 +165,6 @@ static void arc_pgu_crtc_atomic_begin(struct drm_crtc
> *crtc,
> .disable= arc_pgu_crtc_disable,
> .prepare= arc_pgu_crtc_disable,
> .commit = arc_pgu_crtc_enable,
> - .atomic_check = arc_pgu_crtc_atomic_check,
> .atomic_begin = arc_pgu_crtc_atomic_begin,
> };
>
[PATCH net-next 0/2] net: stmmac: Support DWMAC5 and TSN
Hi, This adds support for a new IP version (5) of dwmac and for TSN features as defined by IEEE802.1Qbv-2015 and IEEE802.1Qbu. Please review. Best regards, Jose Miguel Abreu Jose Abreu (2): net: stmmac: Add support for DWMAC5 with TSN features bindings: net: stmmac: Add documentation for TSN parameters Documentation/devicetree/bindings/net/stmmac.txt | 20 + drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +- drivers/net/ethernet/stmicro/stmmac/common.h | 4 + drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 37 +++- drivers/net/ethernet/stmicro/stmmac/dwmac5_tsn.c | 99 ++ drivers/net/ethernet/stmicro/stmmac/dwmac5_tsn.h | 57 + drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 + .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 57 - include/linux/stmmac.h | 11 +++ 9 files changed, 288 insertions(+), 3 deletions(-) create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac5_tsn.c create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac5_tsn.h -- 1.9.1
[PATCH net-next 1/2] net: stmmac: Add support for DWMAC5 with TSN features
This adds support for IP version 5 of DWMAC. The new introduced
features are the Enhancements to Scheduled Traffic (EST) as
defined by IEEE802.1Qbv-2015 and Frame Preemption (FPE) as
defined by IEEE802.1Qbu.
In order to not break previous setups all the necessary
configuration is only performed when GMAC5 is detected and
only when all the necessary parameters are available in the
Device Tree.
EST:
The IEEE802.1Qbv-2015 defines the schedule for each of the
queues which makes the IP aware of traffic arrival time. This
information can be used to block the lower priority traffic
from transmission in this time window/slot.
FPE:
The IEEE802.1Qbu defines a mechanism which breaks interfering
frames into smaller fragments shuch that we have a more efficient
use of network bandwidth. This needs EST enabled.
Signed-off-by: Jose Abreu
Cc: David S. Miller
Cc: Joao Pinto
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
---
drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +-
drivers/net/ethernet/stmicro/stmmac/common.h | 4 +
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 37 +++-
drivers/net/ethernet/stmicro/stmmac/dwmac5_tsn.c | 99 ++
drivers/net/ethernet/stmicro/stmmac/dwmac5_tsn.h | 57 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 57 -
include/linux/stmmac.h | 11 +++
8 files changed, 268 insertions(+), 3 deletions(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac5_tsn.c
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac5_tsn.h
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 238307f..45b594e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -3,7 +3,7 @@ stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o
ring_mode.o \
chain_mode.o dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
mmc_core.o stmmac_hwtstamp.o stmmac_ptp.o dwmac4_descs.o \
- dwmac4_dma.o dwmac4_lib.o dwmac4_core.o $(stmmac-y)
+ dwmac4_dma.o dwmac4_lib.o dwmac4_core.o dwmac5_tsn.o $(stmmac-y)
# Ordering matters. Generic driver must be last.
obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index e1e5ac0..d052b9f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -38,6 +38,7 @@
#defineDWMAC_CORE_3_40 0x34
#defineDWMAC_CORE_3_50 0x35
#defineDWMAC_CORE_4_00 0x40
+#define DWMAC_CORE_5_00 0x50
#define STMMAC_CHAN0 0 /* Always supported and default for all chips */
/* These need to be power of two, and >= 4 */
@@ -501,6 +502,9 @@ struct stmmac_ops {
void (*config_cbs)(struct mac_device_info *hw, u32 send_slope,
u32 idle_slope, u32 high_credit, u32 low_credit,
u32 queue);
+ /* Configure TSN features */
+ void (*config_tsn)(struct mac_device_info *hw,
+ struct plat_stmmacenet_data *plat);
/* Dump MAC registers */
void (*dump_regs)(struct mac_device_info *hw, u32 *reg_space);
/* Handle extra events on specific interrupts hw dependent */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 2f7d7ec..54370da 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -19,6 +19,7 @@
#include
#include "stmmac_pcs.h"
#include "dwmac4.h"
+#include "dwmac5_tsn.h"
static void dwmac4_core_init(struct mac_device_info *hw, int mtu)
{
@@ -738,6 +739,38 @@ static void dwmac4_debug(void __iomem *ioaddr, struct
stmmac_extra_stats *x,
.set_filter = dwmac4_set_filter,
};
+static const struct stmmac_ops dwmac5_ops = {
+ .core_init = dwmac4_core_init,
+ .set_mac = stmmac_dwmac4_set_mac,
+ .rx_ipc = dwmac4_rx_ipc_enable,
+ .rx_queue_enable = dwmac4_rx_queue_enable,
+ .rx_queue_prio = dwmac4_rx_queue_priority,
+ .tx_queue_prio = dwmac4_tx_queue_priority,
+ .rx_queue_routing = dwmac4_tx_queue_routing,
+ .prog_mtl_rx_algorithms = dwmac4_prog_mtl_rx_algorithms,
+ .prog_mtl_tx_algorithms = dwmac4_prog_mtl_tx_algorithms,
+ .set_mtl_tx_queue_weight = dwmac4_set_mtl_tx_queue_weight,
+ .map_mtl_to_dma = dwmac4_map_mtl_dma,
+ .config_cbs = dwmac4_config_cbs,
+ .config_tsn = dwmac5_config_tsn,
+ .dump_regs = dwmac4_dump_regs,
+ .host_irq_status = dwmac4_irq_status,
+ .host_mtl_irq_status = dwmac4_irq_mtl_status,
+ .flow_ctrl
[PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters
This adds the documentation for TSN feature EST and FP.
Signed-off-by: Jose Abreu
Cc: David S. Miller
Cc: Joao Pinto
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Rob Herring
---
Documentation/devicetree/bindings/net/stmmac.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index c3a7be6..6359df6 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -114,6 +114,16 @@ Optional properties:
- snps,high_credit: max write outstanding req. limit
- snps,low_credit: max read outstanding req. limit
- snps,priority: TX queue priority (Range: 0x0 to 0xF)
+- TSN parameters: below the list of all the parameters to configure TSN
+ features (only applicable for IP version >= 5.00)
+ - snps,est: Enable EST algorithm
+ - If EST enabled provide these parameters:
+ - snps,btr: Array size of 2 with BTR value for EST algorithm
+ - snps,ctr: Array size of 2 with CTR value for EST algorithm
+ - snps,ter: TER value for EST algorithm
+ - snps,gcl: Variable size array with GCL table entries.
+ - snps,fp: Enable FP feature. This needs EST enabled.
+
Examples:
stmmac_axi_setup: stmmac-axi-config {
@@ -151,6 +161,15 @@ Examples:
};
};
+ tsn_setup: tsn-config {
+ snps,est;
+ snps,btr = <0x 0x0001>;
+ snps,ctr = <0x 0x1000>;
+ snps,ter = <0x>;
+ snps,gcl = <0x0001 0x0002 0x0003>;
+ snps,fp;
+ };
+
gmac0: ethernet@e080 {
compatible = "st,spear600-gmac";
reg = <0xe080 0x8000>;
@@ -176,4 +195,5 @@ Examples:
};
snps,mtl-rx-config = <&mtl_rx_setup>;
snps,mtl-tx-config = <&mtl_tx_setup>;
+ snps,tsn-config = <&tsn_setup>;
};
--
1.9.1
Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters
Hi Florian,
On 25-10-2017 20:34, Florian Fainelli wrote:
> On 10/25/2017 07:04 AM, Jose Abreu wrote:
>> This adds the documentation for TSN feature EST and FP.
>>
>> Signed-off-by: Jose Abreu
>> Cc: David S. Miller
>> Cc: Joao Pinto
>> Cc: Giuseppe Cavallaro
>> Cc: Alexandre Torgue
>> Cc: Rob Herring
>> ---
>> Documentation/devicetree/bindings/net/stmmac.txt | 20
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
>> b/Documentation/devicetree/bindings/net/stmmac.txt
>> index c3a7be6..6359df6 100644
>> --- a/Documentation/devicetree/bindings/net/stmmac.txt
>> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
>> @@ -114,6 +114,16 @@ Optional properties:
>> - snps,high_credit: max write outstanding req. limit
>> - snps,low_credit: max read outstanding req. limit
>> - snps,priority: TX queue priority (Range: 0x0 to 0xF)
>> +- TSN parameters: below the list of all the parameters to configure TSN
>> + features (only applicable for IP version >= 5.00)
>> +- snps,est: Enable EST algorithm
>> +- If EST enabled provide these parameters:
>> +- snps,btr: Array size of 2 with BTR value for EST algorithm
>> +- snps,ctr: Array size of 2 with CTR value for EST algorithm
>> +- snps,ter: TER value for EST algorithm
>> +- snps,gcl: Variable size array with GCL table entries.
>> +- snps,fp: Enable FP feature. This needs EST enabled.
> You are using Device Tree as a configuration interface, that does not
> sound right at all.
>
>> +
>> Examples:
>>
>> stmmac_axi_setup: stmmac-axi-config {
>> @@ -151,6 +161,15 @@ Examples:
>> };
>> };
>>
>> +tsn_setup: tsn-config {
>> +snps,est;
>> +snps,btr = <0x 0x0001>;
>> +snps,ctr = <0x 0x1000>;
>> +snps,ter = <0x>;
>> +snps,gcl = <0x0001 0x0002 0x0003>;
>> +snps,fp;
>> +};
>> +
>> gmac0: ethernet@e080 {
>> compatible = "st,spear600-gmac";
>> reg = <0xe080 0x8000>;
>> @@ -176,4 +195,5 @@ Examples:
>> };
>> snps,mtl-rx-config = <&mtl_rx_setup>;
>> snps,mtl-tx-config = <&mtl_tx_setup>;
>> +snps,tsn-config = <&tsn_setup>;
> Yes, this is definitively using Device Tree as a configuration
> interface, don't do that please.
I understand your concern here and I know DT bindings should only
describe the HW but note that this is already done in
mtl-rx-config and mtl-tx-config.
These parameters may also need to change in runtime depending on
the scheduled traffic. Unfortunately, net subsystem does not yet
support TSN so this will have to wait and for now we will use
fixed parameters.
Anyway, what do you suggest here instead? Platform data?
Best regards,
Jose Miguel Abreu
[PATCH net] net: stmmac: dwc-qos-eth: Fix typo in DT bindings parsing
According to DT bindings documentation we are expecting a
property called "snps,read-requests" but we are parsing
instead a property called "read,read-requests".
This is clearly a typo. Fix it.
Signed-off-by: Jose Abreu
Cc: Joao Pinto
Cc: David S. Miller
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
---
drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index 5efef80..3256e5c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -74,7 +74,7 @@ static int dwc_eth_dwmac_config_dt(struct platform_device
*pdev,
plat_dat->axi->axi_wr_osr_lmt--;
}
- if (of_property_read_u32(np, "read,read-requests",
+ if (of_property_read_u32(np, "snps,read-requests",
&plat_dat->axi->axi_rd_osr_lmt)) {
/**
* Since the register has a reset value of 1, if property
--
1.9.1
[PATCH net] net: stmmac: First Queue must always be in DCB mode
According to DWMAC databook the first queue operating mode must always be in DCB. As MTL_QUEUE_DCB = 1, we need to always set the first queue operating mode to DCB otherwise driver will think that queue is in AVB mode (because MTL_QUEUE_AVB = 0). Signed-off-by: Jose Abreu Cc: Joao Pinto Cc: David S. Miller Cc: Giuseppe Cavallaro Cc: Alexandre Torgue --- drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c index 21f59fe..603225b 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c @@ -150,6 +150,13 @@ static void stmmac_mtl_setup(struct platform_device *pdev, plat->rx_queues_to_use = 1; plat->tx_queues_to_use = 1; + /* First Queue must always be in DCB mode. As MTL_QUEUE_DCB = 1 we need +* to always set this, otherwise Queue will be classified as AVB +* (because MTL_QUEUE_AVB = 0). +*/ + plat->rx_queues_cfg[0].mode_to_use = MTL_QUEUE_DCB; + plat->tx_queues_cfg[0].mode_to_use = MTL_QUEUE_DCB; + rx_node = of_parse_phandle(pdev->dev.of_node, "snps,mtl-rx-config", 0); if (!rx_node) return; -- 1.9.1
Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters
Hi Andrew, On 26-10-2017 10:03, Andrew Lunn wrote: >> These parameters may also need to change in runtime depending on >> the scheduled traffic. Unfortunately, net subsystem does not yet >> support TSN so this will have to wait and for now we will use >> fixed parameters. > Hi Jose > > what you should do is help Linux get support for TSN. Please take part > in this discussion: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_cover_808504_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=8yzdm5iHyWm9cVsYIYUtQNul5WnLO4nLnIxb3WDu-WU&s=6UJ2YJm5jXq6vTWpNRwRzNEuukPboceO61DQgDIpSj0&e= Seems like I don't have this thread saved here. Can you please add me in the thread? Thanks and best regards, Jose Miguel Abreu > > Test the RFC, make sure the concepts will work for your hardware. Make > you hardware work with these RFC patches. Help drive TSN forward. Once > the core TSN code lands, then you can post patches for your driver. > > Andrew
Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters
Hi Andrew, On 26-10-2017 10:03, Andrew Lunn wrote: >> These parameters may also need to change in runtime depending on >> the scheduled traffic. Unfortunately, net subsystem does not yet >> support TSN so this will have to wait and for now we will use >> fixed parameters. > Hi Jose > > what you should do is help Linux get support for TSN. Please take part > in this discussion: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_cover_808504_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=8yzdm5iHyWm9cVsYIYUtQNul5WnLO4nLnIxb3WDu-WU&s=6UJ2YJm5jXq6vTWpNRwRzNEuukPboceO61DQgDIpSj0&e= > > Test the RFC, make sure the concepts will work for your hardware. Make > you hardware work with these RFC patches. Help drive TSN forward. Once > the core TSN code lands, then you can post patches for your driver. After reading more carefully the RFC I noticed that for now it only supports CBS. CBS is already supported by stmmac since: "net: stmmac: configuration of CBS in case of a TX AVB queue" [1]. My main objective now is to add support for EST and FP features in stmmac. As I am a recent contributor to net subsytem I am afraid my expertise won't be of much value for now as far as the RFC goes. About my patches, what I think would be better now would be to drop the configuration by DT and integrate the remaining configuration, letting the EST parameters be populated by SoC specific wrappers. I will then integrate this with the RFC patches once they get in and I also intend to contribute with the discussion once a new version is sent. I need also to say that this was fully tested and its working as expected so, there is no real setback in integrating this now and it will save us time in the future because then we will only need to implement the callbacks. Best regards, Jose Miguel Abreu [1] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/drivers/net/ethernet/stmicro/stmmac?id=19d9187317979cf0c25f67017d2676149abc46b2 > > Andrew
Re: [PATCH net] net: stmmac: First Queue must always be in DCB mode
Hi Bhadram, On 26-10-2017 11:51, Bhadram Varka wrote: > Hi Jose, > >> -Original Message- >> From: netdev-ow...@vger.kernel.org [mailto:netdev- >> ow...@vger.kernel.org] On Behalf Of Jose Abreu >> Sent: Thursday, October 26, 2017 2:37 PM >> To: net...@vger.kernel.org; linux-kernel@vger.kernel.org >> Cc: Jose Abreu ; Joao Pinto >> ; David S. Miller ; >> Giuseppe Cavallaro ; Alexandre Torgue >> >> Subject: [PATCH net] net: stmmac: First Queue must always be in DCB mode >> >> According to DWMAC databook the first queue operating mode must always >> be in DCB. >> >> As MTL_QUEUE_DCB = 1, we need to always set the first queue operating >> mode to DCB otherwise driver will think that queue is in AVB mode (because >> MTL_QUEUE_AVB = 0). >> >> Signed-off-by: Jose Abreu >> Cc: Joao Pinto >> Cc: David S. Miller >> Cc: Giuseppe Cavallaro >> Cc: Alexandre Torgue >> --- >> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c >> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c >> index 21f59fe..603225b 100644 >> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c >> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c >> @@ -150,6 +150,13 @@ static void stmmac_mtl_setup(struct >> platform_device *pdev, >> plat->rx_queues_to_use = 1; >> plat->tx_queues_to_use = 1; >> >> +/* First Queue must always be in DCB mode. As MTL_QUEUE_DCB = >> 1 we need >> + * to always set this, otherwise Queue will be classified as AVB >> + * (because MTL_QUEUE_AVB = 0). >> + */ > Its better if we can check whether IP HW features (register - 0x120) supports > the DCB or not. If yes, then set the DCB mode. > There is possibility that DCB feature not enable for few of the Synopsys IP's. A queue can either be in Generic/DCB or AVB mode. The sequence to enable a DCB or a Generic queue is the same so there is no need to check for DCB capability in HW. Best Regards, Jose Miguel Abreu > > Thanks, > Bhadram.
Re: [PATCH net] net: stmmac: First Queue must always be in DCB mode
On 26-10-2017 15:44, Bhadram Varka wrote: > Hi Jose, > >> -Original Message----- >> From: Jose Abreu [mailto:jose.ab...@synopsys.com] >> Sent: Thursday, October 26, 2017 5:19 PM >> To: Bhadram Varka ; net...@vger.kernel.org; >> linux-kernel@vger.kernel.org >> Cc: Joao Pinto ; David S. Miller >> ; Giuseppe Cavallaro ; >> Alexandre Torgue >> Subject: Re: [PATCH net] net: stmmac: First Queue must always be in DCB >> mode >> >> Hi Bhadram, >> >> On 26-10-2017 11:51, Bhadram Varka wrote: >>> Hi Jose, >>> >>>> -Original Message- >>>> From: netdev-ow...@vger.kernel.org [mailto:netdev- >>>> ow...@vger.kernel.org] On Behalf Of Jose Abreu >>>> Sent: Thursday, October 26, 2017 2:37 PM >>>> To: net...@vger.kernel.org; linux-kernel@vger.kernel.org >>>> Cc: Jose Abreu ; Joao Pinto >>>> ; David S. Miller ; >>>> Giuseppe Cavallaro ; Alexandre Torgue >>>> >>>> Subject: [PATCH net] net: stmmac: First Queue must always be in DCB >>>> mode >>>> >>>> According to DWMAC databook the first queue operating mode must >>>> always be in DCB. >>>> >>>> As MTL_QUEUE_DCB = 1, we need to always set the first queue operating >>>> mode to DCB otherwise driver will think that queue is in AVB mode >>>> (because MTL_QUEUE_AVB = 0). >>>> >>>> Signed-off-by: Jose Abreu >>>> Cc: Joao Pinto >>>> Cc: David S. Miller >>>> Cc: Giuseppe Cavallaro >>>> Cc: Alexandre Torgue >>>> --- >>>> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 7 +++ >>>> 1 file changed, 7 insertions(+) >>>> >>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c >>>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c >>>> index 21f59fe..603225b 100644 >>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c >>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c >>>> @@ -150,6 +150,13 @@ static void stmmac_mtl_setup(struct >>>> platform_device *pdev, >>>>plat->rx_queues_to_use = 1; >>>>plat->tx_queues_to_use = 1; >>>> >>>> + /* First Queue must always be in DCB mode. As MTL_QUEUE_DCB = >>>> 1 we need >>>> + * to always set this, otherwise Queue will be classified as AVB >>>> + * (because MTL_QUEUE_AVB = 0). >>>> + */ >>> Its better if we can check whether IP HW features (register - 0x120) >> supports the DCB or not. If yes, then set the DCB mode. >>> There is possibility that DCB feature not enable for few of the Synopsys >> IP's. >> >> A queue can either be in Generic/DCB or AVB mode. The sequence to enable >> a DCB or a Generic queue is the same so there is no need to check for DCB >> capability in HW. > Point is that we don't have DCB enabled for the IP. > > From your point it will work in Generic (legacy) mode if we set DCB filed. If > this is the understanding then we are fine. Yes, thats true. Generic and DCB have the same configuration. Best Regards, Jose Miguel Abreu > > Thanks, > Bhadram.
Re: [PATCH net-next 0/2] net: stmmac: Support DWMAC5 and TSN
Hi Jesus, On 26-10-2017 17:28, Jesus Sanchez-Palencia wrote: > Hi Jose, > > > On 10/25/2017 07:02 AM, Jose Abreu wrote: >> Hi, >> >> This adds support for a new IP version (5) of dwmac and for >> TSN features as defined by IEEE802.1Qbv-2015 and IEEE802.1Qbu. > > Just out of curiosity, are you aware of any NICs that are publicly > available which use this IP version? The IP was just released and these are fresh new features, you can find more info here [1]. We expect manufacturers to start adopting this IP release soon. Best Regards, Jose Miguel Abreu [1] https://www.synopsys.com/dw/ipdir.php?ds=dwc_ether_qos > > Thanks, > Jesus > > >> Please review. >> >> Best regards, >> Jose Miguel Abreu >> >> Jose Abreu (2): >> net: stmmac: Add support for DWMAC5 with TSN features >> bindings: net: stmmac: Add documentation for TSN parameters >> >> Documentation/devicetree/bindings/net/stmmac.txt | 20 + >> drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +- >> drivers/net/ethernet/stmicro/stmmac/common.h | 4 + >> drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 37 +++- >> drivers/net/ethernet/stmicro/stmmac/dwmac5_tsn.c | 99 >> ++ >> drivers/net/ethernet/stmicro/stmmac/dwmac5_tsn.h | 57 + >> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 + >> .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 57 - >> include/linux/stmmac.h | 11 +++ >> 9 files changed, 288 insertions(+), 3 deletions(-) >> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac5_tsn.c >> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac5_tsn.h >>
Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters
Hi Jesus, On 26-10-2017 17:23, Jesus Sanchez-Palencia wrote: > Hi Jose, > > > On 10/26/2017 03:08 AM, Jose Abreu wrote: >> Hi Andrew, >> >> On 26-10-2017 10:03, Andrew Lunn wrote: >>>> These parameters may also need to change in runtime depending on >>>> the scheduled traffic. Unfortunately, net subsystem does not yet >>>> support TSN so this will have to wait and for now we will use >>>> fixed parameters. >>> Hi Jose >>> >>> what you should do is help Linux get support for TSN. Please take part >>> in this discussion: >>> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_cover_808504_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=8yzdm5iHyWm9cVsYIYUtQNul5WnLO4nLnIxb3WDu-WU&s=6UJ2YJm5jXq6vTWpNRwRzNEuukPboceO61DQgDIpSj0&e= >>> >>> Test the RFC, make sure the concepts will work for your hardware. Make >>> you hardware work with these RFC patches. Help drive TSN forward. Once >>> the core TSN code lands, then you can post patches for your driver. >> After reading more carefully the RFC I noticed that for now it >> only supports CBS. CBS is already supported by stmmac since: >> "net: stmmac: configuration of CBS in case of a TX AVB queue" >> [1]. My main objective now is to add support for EST and FP >> features in stmmac. >> >> As I am a recent contributor to net subsystem I am afraid my >> expertise won't be of much value for now as far as the RFC goes. >> > > Please note that our RFC covered more than CBS. We've only provided > patches for the cbs qdisc so far, but we've shared ideas of another > qdisc we've designed and prototyped for EST and FP: taprio. It was a > quite extensive thread, so I recommend reading it all so you can have > a better picture of how the ideas were received back then [1]. > > In addition to our RFC, there is also the related discussion about > SO_TXTIME proposed by Richard Cochran [2], which I believe might > also be of interest to you. Thanks for this info! I guess I have a lot to read this weekend :) > > >> About my patches, what I think would be better now would be to >> drop the configuration by DT and integrate the remaining >> configuration, letting the EST parameters be populated by SoC >> specific wrappers. I will then integrate this with the RFC >> patches once they get in and I also intend to contribute with the >> discussion once a new version is sent. > > The CBS qdisc patchset is ready to be merged, and based on previous > feedback should go in anytime now. Nice! I will start studying the integration of this in stmmac. > > >> I need also to say that this was fully tested and its working as >> expected so, there is no real setback in integrating this now and >> it will save us time in the future because then we will only need >> to implement the callbacks. > > Which is great, sure. I believe the point others are making here is > just that there have been some discussions recently that you should > take part of. The goal is getting the *standard* interfaces into > the kernel so we can then provide device driver implementations > through them. And we are all in favor about making this a standard interface. I was just mentioning that my expertise in the net subsystem is very low but I will review the threads. If you could add me in cc for the relevant threads it would be nice because I don't have them saved here. Thanks and Best Regards, Jose Miguel Abreu > > Thanks, > Jesus > > [1] > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchive.com_netdev-40vger.kernel.org_msg186431.html&d=DwIC-g&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=9feTUzfFG49lrNpaBinz8J4S1cKj1qEZur1JlzfQdWU&s=zjR6UPefwbqwHVbaTrepj_ZQnxBMGKDlTq4obkLlfkk&e= > [2] > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchive.com_netdev-40vger.kernel.org_msg188385.html&d=DwIC-g&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=9feTUzfFG49lrNpaBinz8J4S1cKj1qEZur1JlzfQdWU&s=6aZXBf8OndxVnh1cl3UvvfDqWp1Xa6ql_cCVB3xAQa8&e= > > >> Best regards, >> Jose Miguel Abreu >> >> [1] >> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_davem_net-2Dnext.git_commit_drivers_net_ethernet_stmicro_stmmac-3Fid-3D19d9187317979cf0c25f67017d2676149abc46b2&d=DwIC-g&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=9feTUzfFG49lrNpaBinz8J4S1cKj1qEZur1JlzfQdWU&s=kN0fG9BlqONAd9z6vji-mnCxaVpJ-oX-Bv4c6DXNhaQ&e= >> >>> Andrew
Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters
Hi Andrew, On 26-10-2017 22:56, Andrew Lunn wrote: >> About my patches, what I think would be better now would be to >> drop the configuration by DT and integrate the remaining >> configuration, letting the EST parameters be populated by SoC >> specific wrappers. > Hi Jose > > The problem with SoC specific wrappers is that you are going to have > to remove them once the real interface is defined. Anybody who uses > your SoC specific wrappers is going to have to re-write their code, > when it all gets ripped out. Yeah, I agree. But what about just merge the implementation and then construct the interface? I mean just creating the internal parameters in stmmac and then the configuration functions. > > You generally don't add device SoC specific wrappers. Imagine if > everybody did that. Lots of different ways of doing the same thing. > My suggesting is to keep your patches out for the moment, waiting for > generic support to be added. I think we should take advantage of the fact that this is working and ready to be merged. Its just HW configuration but maybe it can serve as momentum for other drivers to also integrate this? Best Regards, Jose Miguel Abreu > > Andrew
Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters
Hi Peppe, On 27-10-2017 13:29, Giuseppe CAVALLARO wrote: > Hello > > On 10/27/2017 11:05 AM, Jose Abreu wrote: >> I think we should take advantage of the fact that this is working >> and ready to be merged. Its just HW configuration but maybe it >> can serve as momentum for other drivers to also integrate this? > > Let me propose to have it now in the next-next. > > This support is for dwmac 5.x so no disturb for the common > driver APIs and there is no risk to have regressions, IMO. > > IIUC, you already tested it on a real environment that > sounds to be very good progress. Ok, I will drop this documentation patch and the DT parsing and send a new version. Best Regards, Jose Miguel Abreu > > Regards > Peppe > >> Best Regards, >> Jose Miguel Abreu > >
[PATCH v2 net-next] net: stmmac: Add support for DWMAC5 with TSN features
This adds support for IP version 5 of DWMAC. The new introduced
features are the Enhancements to Scheduled Traffic (EST) as
defined by IEEE802.1Qbv-2015 and Frame Preemption (FPE) as
defined by IEEE802.1Qbu.
In order to not break previous setups all the necessary
configuration is only performed when GMAC5 is detected and
only when all the necessary parameters are available in the
Device Tree.
EST:
The IEEE802.1Qbv-2015 defines the schedule for each of the
queues which makes the IP aware of traffic arrival time. This
information can be used to block the lower priority traffic
from transmission in this time window/slot.
FPE:
The IEEE802.1Qbu defines a mechanism which breaks interfering
frames into smaller fragments shuch that we have a more efficient
use of network bandwidth. This needs EST enabled.
Signed-off-by: Jose Abreu
Cc: David S. Miller
Cc: Joao Pinto
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
---
Changes since v1:
- Removed DT parsing
---
drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +-
drivers/net/ethernet/stmicro/stmmac/common.h | 4 +
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 37 +++-
drivers/net/ethernet/stmicro/stmmac/dwmac5_tsn.c | 99 ++
drivers/net/ethernet/stmicro/stmmac/dwmac5_tsn.h | 57 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 +-
include/linux/stmmac.h | 11 +++
8 files changed, 214 insertions(+), 3 deletions(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac5_tsn.c
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac5_tsn.h
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 238307f..45b594e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -3,7 +3,7 @@ stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o
ring_mode.o \
chain_mode.o dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
mmc_core.o stmmac_hwtstamp.o stmmac_ptp.o dwmac4_descs.o \
- dwmac4_dma.o dwmac4_lib.o dwmac4_core.o $(stmmac-y)
+ dwmac4_dma.o dwmac4_lib.o dwmac4_core.o dwmac5_tsn.o $(stmmac-y)
# Ordering matters. Generic driver must be last.
obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index e1e5ac0..d052b9f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -38,6 +38,7 @@
#defineDWMAC_CORE_3_40 0x34
#defineDWMAC_CORE_3_50 0x35
#defineDWMAC_CORE_4_00 0x40
+#define DWMAC_CORE_5_00 0x50
#define STMMAC_CHAN0 0 /* Always supported and default for all chips */
/* These need to be power of two, and >= 4 */
@@ -501,6 +502,9 @@ struct stmmac_ops {
void (*config_cbs)(struct mac_device_info *hw, u32 send_slope,
u32 idle_slope, u32 high_credit, u32 low_credit,
u32 queue);
+ /* Configure TSN features */
+ void (*config_tsn)(struct mac_device_info *hw,
+ struct plat_stmmacenet_data *plat);
/* Dump MAC registers */
void (*dump_regs)(struct mac_device_info *hw, u32 *reg_space);
/* Handle extra events on specific interrupts hw dependent */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 2f7d7ec..54370da 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -19,6 +19,7 @@
#include
#include "stmmac_pcs.h"
#include "dwmac4.h"
+#include "dwmac5_tsn.h"
static void dwmac4_core_init(struct mac_device_info *hw, int mtu)
{
@@ -738,6 +739,38 @@ static void dwmac4_debug(void __iomem *ioaddr, struct
stmmac_extra_stats *x,
.set_filter = dwmac4_set_filter,
};
+static const struct stmmac_ops dwmac5_ops = {
+ .core_init = dwmac4_core_init,
+ .set_mac = stmmac_dwmac4_set_mac,
+ .rx_ipc = dwmac4_rx_ipc_enable,
+ .rx_queue_enable = dwmac4_rx_queue_enable,
+ .rx_queue_prio = dwmac4_rx_queue_priority,
+ .tx_queue_prio = dwmac4_tx_queue_priority,
+ .rx_queue_routing = dwmac4_tx_queue_routing,
+ .prog_mtl_rx_algorithms = dwmac4_prog_mtl_rx_algorithms,
+ .prog_mtl_tx_algorithms = dwmac4_prog_mtl_tx_algorithms,
+ .set_mtl_tx_queue_weight = dwmac4_set_mtl_tx_queue_weight,
+ .map_mtl_to_dma = dwmac4_map_mtl_dma,
+ .config_cbs = dwmac4_config_cbs,
+ .config_tsn = dwmac5_config_tsn,
+ .dump_regs = dwmac4_dump_regs,
+ .host_irq_status = dwmac4_irq_status,
+ .host_mtl_irq_status = dwmac4_i
Re: [PATCH] Revert "net: stmmac: Do not keep rearming the coalesce timer in stmmac_xmit"
Hi Jerome, On 24-08-2018 10:04, Jerome Brunet wrote: > This reverts commit 4ae0169fd1b3c792b66be58995b7e6b629919ecf. > > This change in the handling of the coalesce timer is causing regression on > (at least) amlogic platforms. > > Network will break down very quickly (a few seconds) after starting > a download. This can easily be reproduced using iperf3 for example. > > The problem has been reported on the S805, S905, S912 and A113 SoCs > (Realtek and Micrel PHYs) and it is likely impacting all Amlogics > platforms using Gbit ethernet > > No problem was seen with the platform using 10/100 only PHYs (GXL internal) > > Reverting change brings things back to normal and allows to use network > again until we better understand the problem with the coalesce timer. > > Apologies for the delayed answer but I was in FTO. I'm not sure what can be causing this but I have some questions for you: - What do you mean by "network will break down"? Do you see queue timeout? - What do you see in ethtool/ifconfig stats? Can you send me the stats before and after network break? - Is your setup multi-queue/channel? - Can you point me to the DT bindings of your setup? Thanks and Best Regards, Jose Miguel Abreu
[PATCH v3 2/6] drm: Add drm_{crtc/encoder/connector}_mode_valid()
Add a new helper to call crtc->mode_valid, connector->mode_valid
and encoder->mode_valid callbacks.
Suggested-by: Ville Syrjälä
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Andrzej Hajda
Cc: Archit Taneja
---
Changes v2->v3:
- Move helpers to drm_probe_helper.c (Daniel)
- Squeeze patches that introduce the helpers into a single
one (Daniel)
drivers/gpu/drm/drm_crtc_helper_internal.h | 13 ++
drivers/gpu/drm/drm_probe_helper.c | 38 ++
2 files changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc_helper_internal.h
b/drivers/gpu/drm/drm_crtc_helper_internal.h
index 28295e5..97dfe20 100644
--- a/drivers/gpu/drm/drm_crtc_helper_internal.h
+++ b/drivers/gpu/drm/drm_crtc_helper_internal.h
@@ -26,7 +26,11 @@
* implementation details and are not exported to drivers.
*/
+#include
+#include
#include
+#include
+#include
/* drm_fb_helper.c */
#ifdef CONFIG_DRM_FBDEV_EMULATION
@@ -62,4 +66,13 @@ static inline int drm_dp_aux_register_devnode(struct
drm_dp_aux *aux)
static inline void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux)
{
}
+
+/* drm_probe_helper.c */
+enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode *mode);
+enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
+ const struct drm_display_mode
*mode);
+enum drm_mode_status drm_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode);
+
#endif
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 1b0c14a..f01abdc 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -38,6 +38,9 @@
#include
#include
#include
+#include
+
+#include "drm_crtc_helper_internal.h"
/**
* DOC: output probing helper overview
@@ -113,6 +116,41 @@ static int drm_helper_probe_add_cmdline_mode(struct
drm_connector *connector)
return 1;
}
+enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode *mode)
+{
+ const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
+
+ if (!crtc_funcs || !crtc_funcs->mode_valid)
+ return MODE_OK;
+
+ return crtc_funcs->mode_valid(crtc, mode);
+}
+
+enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
+ const struct drm_display_mode *mode)
+{
+ const struct drm_encoder_helper_funcs *encoder_funcs =
+ encoder->helper_private;
+
+ if (!encoder_funcs || !encoder_funcs->mode_valid)
+ return MODE_OK;
+
+ return encoder_funcs->mode_valid(encoder, mode);
+}
+
+enum drm_mode_status drm_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+ const struct drm_connector_helper_funcs *connector_funcs =
+ connector->helper_private;
+
+ if (!connector_funcs || !connector_funcs->mode_valid)
+ return MODE_OK;
+
+ return connector_funcs->mode_valid(connector, mode);
+}
+
#define DRM_OUTPUT_POLL_PERIOD (10*HZ)
/**
* drm_kms_helper_poll_enable - re-enable output polling.
--
1.9.1
[PATCH v3 1/6] drm: Add crtc/encoder/bridge->mode_valid() callbacks
This adds a new callback to crtc, encoder and bridge helper functions
called mode_valid(). This callback shall be implemented if the
corresponding component has some sort of restriction in the modes
that can be displayed. A NULL callback implicates that the component
can display all the modes.
We also change the documentation so that the new and old callbacks
are correctly documented.
Only the callbacks were implemented to simplify review process,
following patches will make use of them.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Andrzej Hajda
Cc: Archit Taneja
---
Changes v2->v3:
- Try to document the callbacks a little bit better and
review current documentation (Daniel)
Changes v1->v2:
- Change description of connector->mode_valid() (Daniel)
include/drm/drm_bridge.h | 20 ++
include/drm/drm_modeset_helper_vtables.h | 110 +++
2 files changed, 103 insertions(+), 27 deletions(-)
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index fdd82fc..00c6c36 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -59,6 +59,26 @@ struct drm_bridge_funcs {
void (*detach)(struct drm_bridge *bridge);
/**
+* @mode_valid:
+*
+* This callback is used to check if a specific mode is valid in this
+* bridge. This should be implemented if the bridge has some sort of
+* restriction in the modes it can display. For example, a given bridge
+* may be responsible to set a clock value. If the clock can not
+* produce all the values for the available modes then this callback
+* can be used to restrict the number of modes to only the ones that
+* can be displayed.
+*
+* This is called at mode probe and at atomic check phase.
+*
+* RETURNS:
+*
+* drm_mode_status Enum
+*/
+ enum drm_mode_status (*mode_valid)(struct drm_bridge *crtc,
+ const struct drm_display_mode *mode);
+
+ /**
* @mode_fixup:
*
* This callback is used to validate and adjust a mode. The paramater
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index c01c328..b07b7cd 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -106,14 +106,37 @@ struct drm_crtc_helper_funcs {
void (*commit)(struct drm_crtc *crtc);
/**
+* @mode_valid:
+*
+* This callback is used to check if a specific mode is valid in this
+* crtc. This should be implemented if the crtc has some sort of
+* restriction in the modes it can display. For example, a given crtc
+* may be responsible to set a clock value. If the clock can not
+* produce all the values for the available modes then this callback
+* can be used to restrict the number of modes to only the ones that
+* can be displayed.
+*
+* This is called at mode probe and at atomic check phase.
+*
+* RETURNS:
+*
+* drm_mode_status Enum
+*/
+ enum drm_mode_status (*mode_valid)(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode);
+
+ /**
* @mode_fixup:
*
-* This callback is used to validate a mode. The parameter mode is the
-* display mode that userspace requested, adjusted_mode is the mode the
-* encoders need to be fed with. Note that this is the inverse semantics
-* of the meaning for the &drm_encoder and &drm_bridge_funcs.mode_fixup
-* vfunc. If the CRTC cannot support the requested conversion from mode
-* to adjusted_mode it should reject the modeset.
+* This callback is used to do the validation of an adjusted mode in the
+* crtc. The parameter mode is the display mode that userspace
requested,
+* adjusted_mode is the mode the encoders need to be fed with. Note that
+* this is the inverse semantics of the meaning for the &drm_encoder and
+* &drm_bridge_funcs.mode_fixup vfunc. If the CRTC cannot support the
+* requested conversion from mode to adjusted_mode it should reject the
+* modeset. Also note that initial validation of a mode supplied by
+* userspace should be done in &drm_crtc_helper_funcs.mode_valid and not
+* in this callback.
*
* This function is used by both legacy CRTC helpers and atomic helpers.
* With atomic helpers it is optional.
@@ -135,17 +158,19 @@ struct drm_crtc_helper_funcs {
* Also beware that neither core nor helpers filter modes before
* passing them to the driver: While the list of modes tha
[PATCH v3 0/6] Introduce new mode validation callbacks
This series is a follow up from the discussion at [1]. We start by
introducing crtc->mode_valid(), encoder->mode_valid() and
bridge->mode_valid() callbacks which will be used in followup
patches and also by cleaning the documentation a little bit.
We proceed by introducing new helpers to call this new callbacks
at 2/6.
At 3/6 a helper function is introduced that calls all mode_valid()
from a set of bridges.
Next, at 4/6 we modify the connector probe helper so that only modes
which are supported by a given bridge+encoder+crtc combination are
probbed.
At 5/6 we call all the mode_valid() callbacks for a given pipeline,
except the connector->mode_valid one, so that the mode is validated.
This is done before calling mode_fixup().
Finally, at 6/6 we use the new crtc->mode_valid() callback in arcpgu
and remove the atomic_check() callback.
[1] https://patchwork.kernel.org/patch/9702233/
Jose Abreu (6):
drm: Add crtc/encoder/bridge->mode_valid() callbacks
drm: Add drm_{crtc/encoder/connector}_mode_valid()
drm: Introduce drm_bridge_mode_valid()
drm: Use new mode_valid() helpers in connector probe helper
drm: Use mode_valid() in atomic modeset
drm: arc: Use crtc->mode_valid() callback
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Andrzej Hajda
Cc: Archit Taneja
drivers/gpu/drm/arc/arcpgu_crtc.c | 39 ++
drivers/gpu/drm/drm_atomic_helper.c| 76 +++-
drivers/gpu/drm/drm_bridge.c | 33 +
drivers/gpu/drm/drm_crtc_helper_internal.h | 13
drivers/gpu/drm/drm_probe_helper.c | 103 ++-
include/drm/drm_bridge.h | 22 ++
include/drm/drm_modeset_helper_vtables.h | 110 ++---
7 files changed, 348 insertions(+), 48 deletions(-)
--
1.9.1
[PATCH v3 6/6] drm: arc: Use crtc->mode_valid() callback
Now that we have a callback to check if crtc supports a given mode
we can use it in arcpgu so that we restrict the number of probbed
modes to the ones we can actually display.
This is specially useful because arcpgu crtc is responsible to set
a clock value in the commit() stage but unfortunatelly this clock
does not support all the needed ranges.
Also, remove the atomic_check() callback as mode_valid() callback
will be called before.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Andrzej Hajda
Cc: Archit Taneja
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 39 ---
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a959..01cae0a 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -32,6 +32,18 @@
{ "r8g8b8", 24, {16, 8}, {8, 8}, {0, 8}, {0, 0}, DRM_FORMAT_RGB888 },
};
+static bool arc_pgu_is_mode_valid(struct arcpgu_drm_private *arcpgu,
+ const struct drm_display_mode *mode)
+{
+ long rate, clk_rate = mode->clock * 1000;
+
+ rate = clk_round_rate(arcpgu->clk, clk_rate);
+ if (rate != clk_rate)
+ return false;
+
+ return true;
+}
+
static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
{
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
@@ -64,6 +76,17 @@ static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
};
+enum drm_mode_status arc_pgu_crtc_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode
*mode)
+{
+ struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
+
+ if (!arc_pgu_is_mode_valid(arcpgu, mode))
+ return MODE_NOCLOCK;
+
+ return MODE_OK;
+}
+
static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
@@ -129,20 +152,6 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
~ARCPGU_CTRL_ENABLE_MASK);
}
-static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
-struct drm_crtc_state *state)
-{
- struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
- struct drm_display_mode *mode = &state->adjusted_mode;
- long rate, clk_rate = mode->clock * 1000;
-
- rate = clk_round_rate(arcpgu->clk, clk_rate);
- if (rate != clk_rate)
- return -EINVAL;
-
- return 0;
-}
-
static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
@@ -158,6 +167,7 @@ static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
}
static const struct drm_crtc_helper_funcs arc_pgu_crtc_helper_funcs = {
+ .mode_valid = arc_pgu_crtc_mode_valid,
.mode_set = drm_helper_crtc_mode_set,
.mode_set_base = drm_helper_crtc_mode_set_base,
.mode_set_nofb = arc_pgu_crtc_mode_set_nofb,
@@ -165,7 +175,6 @@ static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
.disable= arc_pgu_crtc_disable,
.prepare= arc_pgu_crtc_disable,
.commit = arc_pgu_crtc_enable,
- .atomic_check = arc_pgu_crtc_atomic_check,
.atomic_begin = arc_pgu_crtc_atomic_begin,
};
--
1.9.1
[PATCH v3 4/6] drm: Use new mode_valid() helpers in connector probe helper
This changes the connector probe helper function to use the new
encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid()
helper callbacks to validate the modes.
The new callbacks are optional so the behaviour remains the same
if they are not implemented. If they are, then the code loops
through all the connector's encodersXbridgesXcrtcs and calls the
callback.
If at least a valid encoderXbridgeXcrtc combination is found which
accepts the mode then the function returns MODE_OK.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Andrzej Hajda
Cc: Archit Taneja
---
Changes v2->v3:
- Call also bridge->mode_valid (Daniel)
Changes v1->v2:
- Use new helpers suggested by Ville
- Change documentation (Daniel)
drivers/gpu/drm/drm_probe_helper.c | 65 --
1 file changed, 62 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index f01abdc..84d660e 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -83,6 +83,61 @@
return MODE_OK;
}
+static enum drm_mode_status
+drm_mode_validate_connector(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+ struct drm_device *dev = connector->dev;
+ uint32_t *ids = connector->encoder_ids;
+ enum drm_mode_status ret = MODE_OK;
+ unsigned int i;
+
+ /* Step 1: Validate against connector */
+ ret = drm_connector_mode_valid(connector, mode);
+ if (ret != MODE_OK)
+ return ret;
+
+ /* Step 2: Validate against encoders and crtcs */
+ for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
+ struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]);
+ struct drm_crtc *crtc;
+
+ if (!encoder)
+ continue;
+
+ ret = drm_encoder_mode_valid(encoder, mode);
+ if (ret != MODE_OK) {
+ /* No point in continuing for crtc check as this encoder
+* will not accept the mode anyway. If all encoders
+* reject the mode then, at exit, ret will not be
+* MODE_OK. */
+ continue;
+ }
+
+ ret = drm_bridge_mode_valid(encoder->bridge, mode);
+ if (ret != MODE_OK) {
+ /* There is also no point in continuing for crtc check
+* here. */
+ continue;
+ }
+
+ drm_for_each_crtc(crtc, dev) {
+ if (!drm_encoder_crtc_ok(encoder, crtc))
+ continue;
+
+ ret = drm_crtc_mode_valid(crtc, mode);
+ if (ret == MODE_OK) {
+ /* If we get to this point there is at least
+* one combination of encoder+crtc that works
+* for this mode. Lets return now. */
+ return ret;
+ }
+ }
+ }
+
+ return ret;
+}
+
static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector)
{
struct drm_cmdline_mode *cmdline_mode;
@@ -322,7 +377,11 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
*- drm_mode_validate_flag() checks the modes against basic connector
* capabilities (interlace_allowed,doublescan_allowed,stereo_allowed)
*- the optional &drm_connector_helper_funcs.mode_valid helper can perform
- * driver and/or hardware specific checks
+ * driver and/or sink specific checks
+ *- the optional &drm_crtc_helper_funcs.mode_valid,
+ * &drm_bridge_funcs.mode_valid and &drm_encoder_helper_funcs.mode_valid
+ * helpers can perform driver and/or source specific checks which are also
+ * enforced by the modeset/atomic helpers
*
* 5. Any mode whose status is not OK is pruned from the connector's modes
list,
*accompanied by a debug message indicating the reason for the mode's
@@ -466,8 +525,8 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
if (mode->status == MODE_OK)
mode->status = drm_mode_validate_flag(mode, mode_flags);
- if (mode->status == MODE_OK && connector_funcs->mode_valid)
- mode->status = connector_funcs->mode_valid(connector,
+ if (mode->status == MODE_OK)
+ mode->status = drm_mode_validate_connector(connector,
mode);
}
--
1.9.1
[PATCH v3 3/6] drm: Introduce drm_bridge_mode_valid()
Introduce a new helper function which calls mode_valid() callback
for all bridges in an encoder chain.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Andrzej Hajda
Cc: Archit Taneja
---
drivers/gpu/drm/drm_bridge.c | 33 +
include/drm/drm_bridge.h | 2 ++
2 files changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 86a7637..dc8cdfe 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -206,6 +206,39 @@ bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
EXPORT_SYMBOL(drm_bridge_mode_fixup);
/**
+ * drm_bridge_mode_valid - validate the mode against all bridges in the
+ *encoder chain.
+ * @bridge: bridge control structure
+ * @mode: desired mode to be validated
+ *
+ * Calls &drm_bridge_funcs.mode_valid for all the bridges in the encoder
+ * chain, starting from the first bridge to the last. If at least one bridge
+ * does not accept the mode the function returns the error code.
+ *
+ * Note: the bridge passed should be the one closest to the encoder.
+ *
+ * RETURNS:
+ * MODE_OK on success, drm_mode_status Enum error code on failure
+ */
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode)
+{
+ enum drm_mode_status ret = MODE_OK;
+
+ if (!bridge)
+ return ret;
+
+ if (bridge->funcs->mode_valid)
+ ret = bridge->funcs->mode_valid(bridge, mode);
+
+ if (ret != MODE_OK)
+ return ret;
+
+ return drm_bridge_mode_valid(bridge->next, mode);
+}
+EXPORT_SYMBOL(drm_bridge_mode_valid);
+
+/**
* drm_bridge_disable - disables all bridges in the encoder chain
* @bridge: bridge control structure
*
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 00c6c36..8358eb3 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -233,6 +233,8 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct
drm_bridge *bridge,
bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode);
void drm_bridge_disable(struct drm_bridge *bridge);
void drm_bridge_post_disable(struct drm_bridge *bridge);
void drm_bridge_mode_set(struct drm_bridge *bridge,
--
1.9.1
[PATCH v3 5/6] drm: Use mode_valid() in atomic modeset
This patches makes use of the new mode_valid() callbacks introduced
previously to validate the full video pipeline when modesetting.
This calls the encoder->mode_valid(), bridge->mode_valid() and
crtc->mode_valid() so that we can make sure that the mode will
be accepted in every components.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Andrzej Hajda
Cc: Archit Taneja
---
Changes v1->v2:
- Removed call to connector->mode_valid (Ville, Daniel)
- Change function name (Ville)
- Use for_each_new_connector_in_state (Ville)
- Do not validate if connector and mode didn't change (Ville)
- Use new helpers to call mode_valid
drivers/gpu/drm/drm_atomic_helper.c | 76 +++--
1 file changed, 73 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 8be9719..5a3c458 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -32,6 +32,7 @@
#include
#include
+#include "drm_crtc_helper_internal.h"
#include "drm_crtc_internal.h"
/**
@@ -452,6 +453,69 @@ static int handle_conflicting_encoders(struct
drm_atomic_state *state,
return 0;
}
+static enum drm_mode_status mode_valid_path(struct drm_connector *connector,
+ struct drm_encoder *encoder,
+ struct drm_crtc *crtc,
+ struct drm_display_mode *mode)
+{
+ enum drm_mode_status ret;
+
+ ret = drm_encoder_mode_valid(encoder, mode);
+ if (ret != MODE_OK) {
+ DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] mode_valid() failed\n",
+ encoder->base.id, encoder->name);
+ return ret;
+ }
+
+ ret = drm_bridge_mode_valid(encoder->bridge, mode);
+ if (ret != MODE_OK) {
+ DRM_DEBUG_ATOMIC("[BRIDGE] mode_valid() failed\n");
+ return ret;
+ }
+
+ ret = drm_crtc_mode_valid(crtc, mode);
+ if (ret != MODE_OK) {
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] mode_valid() failed\n",
+ crtc->base.id, crtc->name);
+ return ret;
+ }
+
+ return ret;
+}
+
+static int
+mode_valid(struct drm_atomic_state *state)
+{
+ struct drm_connector_state *conn_state;
+ struct drm_connector *connector;
+ int i;
+
+ for_each_new_connector_in_state(state, connector, conn_state, i) {
+ struct drm_encoder *encoder = conn_state->best_encoder;
+ struct drm_crtc *crtc = conn_state->crtc;
+ struct drm_crtc_state *crtc_state;
+ enum drm_mode_status mode_status;
+ struct drm_display_mode *mode;
+
+ if (!crtc || !encoder)
+ continue;
+
+ crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+ if (!crtc_state)
+ continue;
+ if (!crtc_state->mode_changed &&
!crtc_state->connectors_changed)
+ continue;
+
+ mode = &crtc_state->mode;
+
+ mode_status = mode_valid_path(connector, encoder, crtc, mode);
+ if (mode_status != MODE_OK)
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
/**
* drm_atomic_helper_check_modeset - validate state object for modeset changes
* @dev: DRM device
@@ -466,13 +530,15 @@ static int handle_conflicting_encoders(struct
drm_atomic_state *state,
* 2. &drm_connector_helper_funcs.atomic_check to validate the connector state.
* 3. If it's determined a modeset is needed then all connectors on the
affected crtc
*crtc are added and &drm_connector_helper_funcs.atomic_check is run on
them.
- * 4. &drm_bridge_funcs.mode_fixup is called on all encoder bridges.
- * 5. &drm_encoder_helper_funcs.atomic_check is called to validate any encoder
state.
+ * 4. &drm_encoder_helper_funcs.mode_valid, &drm_bridge_funcs.mode_valid and
+ *&drm_crtc_helper_funcs.mode_valid are called on the affected components.
+ * 5. &drm_bridge_funcs.mode_fixup is called on all encoder bridges.
+ * 6. &drm_encoder_helper_funcs.atomic_check is called to validate any encoder
state.
*This function is only called when the encoder will be part of a
configured crtc,
*it must not be used for implementing connector property validation.
*If this function is NULL, &drm_atomic_encoder_helper_funcs.mode_fixup is
called
*instead.
- * 6. &drm_crtc_helper_funcs.mode_fixup is called last, to fix up the mode
with crtc constraints.
+ * 7. &drm_crtc_helper_funcs.mode_fixup is called last,
Re: [PATCH v2 5/8] drm: Use new mode_valid() helpers in connector probe helper
Hi Laurent,
On 12-05-2017 10:35, Laurent Pinchart wrote:
> Hi Jose,
>
> Thank you for the patch.
>
> On Tuesday 09 May 2017 18:00:12 Jose Abreu wrote:
>> This changes the connector probe helper function to use the new
>> encoder->mode_valid() and crtc->mode_valid() helper callbacks to
>> validate the modes.
>>
>> The new callbacks are optional so the behaviour remains the same
>> if they are not implemented. If they are, then the code loops
>> through all the connector's encodersXcrtcs and calls the
>> callback.
>>
>> If at least a valid encoderXcrtc combination is found which
>> accepts the mode then the function returns MODE_OK.
>>
>> Signed-off-by: Jose Abreu
>> Cc: Carlos Palminha
>> Cc: Alexey Brodkin
>> Cc: Ville Syrjälä
>> Cc: Daniel Vetter
>> Cc: Dave Airlie
>> Cc: Andrzej Hajda
>> Cc: Archit Taneja
>> ---
>>
>> Changes v1->v2:
>> - Use new helpers suggested by Ville
>> - Change documentation (Daniel)
>>
>> drivers/gpu/drm/drm_probe_helper.c | 60 +--
>> 1 file changed, 57 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_probe_helper.c
>> b/drivers/gpu/drm/drm_probe_helper.c index 1b0c14a..de47413 100644
>> --- a/drivers/gpu/drm/drm_probe_helper.c
>> +++ b/drivers/gpu/drm/drm_probe_helper.c
>> @@ -39,6 +39,8 @@
>> #include
>> #include
>>
>> +#include "drm_crtc_internal.h"
>> +
>> /**
>> * DOC: output probing helper overview
>> *
>> @@ -80,6 +82,54 @@
>> return MODE_OK;
>> }
>>
>> +static enum drm_mode_status
>> +drm_mode_validate_connector(struct drm_connector *connector,
>> +struct drm_display_mode *mode)
> This does more than validating the mode against the connector, it validates
> it
> against the whole pipeline. I would call the function
> drm_mode_validate_pipeline() (or any other similar name).
Yeah, in previous version I had something similar but I changed
in order to address review comments. I can change again though...
>
>> +{
>> +struct drm_device *dev = connector->dev;
>> +uint32_t *ids = connector->encoder_ids;
>> +enum drm_mode_status ret = MODE_OK;
>> +unsigned int i;
>> +
>> +/* Step 1: Validate against connector */
>> +ret = drm_connector_mode_valid(connector, mode);
>> +if (ret != MODE_OK)
>> +return ret;
>> +
>> +/* Step 2: Validate against encoders and crtcs */
>> +for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
>> +struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]);
>> +struct drm_crtc *crtc;
>> +
>> +if (!encoder)
>> +continue;
>> +
>> +ret = drm_encoder_mode_valid(encoder, mode);
>> +if (ret != MODE_OK) {
>> +/* No point in continuing for crtc check as this
> encoder
>> + * will not accept the mode anyway. If all encoders
>> + * reject the mode then, at exit, ret will not be
>> + * MODE_OK. */
>> +continue;
>> +}
>> +
>> +drm_for_each_crtc(crtc, dev) {
>> +if (!drm_encoder_crtc_ok(encoder, crtc))
>> +continue;
>> +
>> +ret = drm_crtc_mode_valid(crtc, mode);
>> +if (ret == MODE_OK) {
>> +/* If we get to this point there is at least
>> + * one combination of encoder+crtc that works
>> + * for this mode. Lets return now. */
>> +return ret;
>> +}
>> +}
>> +}
>> +
>> +return ret;
>> +}
>> +
>> static int drm_helper_probe_add_cmdline_mode(struct drm_connector
>> *connector)
>> {
>> struct drm_cmdline_mode *cmdline_mode;
>> @@ -284,7 +334,11 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
>> *- drm_mode_validate_flag() checks the modes against basic connector
>> * capabilities (interlace_allowed,doublescan_allowed,stereo_allowed)
>> *- the optional &drm_connector_helper_funcs.mode_valid helper can
>> perform
>> - * driver and/or hardware specific checks
>> + * driver and/or sink specific checks
>> + *- the optional &
Re: [PATCH v2 8/8] drm: arc: Use crtc->mode_valid() callback
Hi Laurent,
Sorry for the late reply.
On 12-05-2017 10:57, Laurent Pinchart wrote:
> Hi Jose,
>
> Thank you for the patch.
>
> On Tuesday 09 May 2017 18:00:15 Jose Abreu wrote:
>> Now that we have a callback to check if crtc supports a given mode
>> we can use it in arcpgu so that we restrict the number of probbed
>> modes to the ones we can actually display.
>>
>> This is specially useful because arcpgu crtc is responsible to set
>> a clock value in the commit() stage but unfortunatelly this clock
>> does not support all the needed ranges.
>>
>> Also, remove the atomic_check() callback as mode_valid() callback
>> will be called before.
>>
>> Signed-off-by: Jose Abreu
>> Cc: Carlos Palminha
>> Cc: Alexey Brodkin
>> Cc: Ville Syrjälä
>> Cc: Daniel Vetter
>> Cc: Dave Airlie
>> Cc: Andrzej Hajda
>> Cc: Archit Taneja
>> ---
>> drivers/gpu/drm/arc/arcpgu_crtc.c | 39 ---
>> 1 file changed, 24 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
>> b/drivers/gpu/drm/arc/arcpgu_crtc.c index ad9a959..01cae0a 100644
>> --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
>> +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
>> @@ -32,6 +32,18 @@
>> { "r8g8b8", 24, {16, 8}, {8, 8}, {0, 8}, {0, 0}, DRM_FORMAT_RGB888 },
>> };
>>
>> +static bool arc_pgu_is_mode_valid(struct arcpgu_drm_private *arcpgu,
>> + const struct drm_display_mode *mode)
>> +{
>> +long rate, clk_rate = mode->clock * 1000;
>> +
>> +rate = clk_round_rate(arcpgu->clk, clk_rate);
>> +if (rate != clk_rate)
>> +return false;
> This isn't anything new introduced by this patch, but shouldn't drivers allow
> for some margin in clock frequencies ? Surely if the mode requires a
> 60.000.000 Hz frequency and the hardware can only generate 59.999.999 Hz or
> 60.000.001 Hz we shouldn't fail. As far as I understand, this is something
> the
> mode_fixup() operation is supposed to handle, but the arc driver doesn't
> implement it.
Its funny you mentioned this because I had exactly the same
discussion with Alexey (arcpgu maintainer) last Friday. Perhaps
we could think about a better way for this.
The main problem is that clock driver does not have all the
available clock values, so some modes will not have a compliant
clock value. Right now we are using clk_round_rate() and checking
if the return value matches the one we supplied, but as you
mentioned for 60vs59.94, for example, the mode will still fail to
commit because the clock will not be the same. We reached to the
conclusion that we could in this function have a max deviation
(which would be determined by max allowed tmds variation in HDMI
spec). What do you think?
Initially my idea was that clock driver should support this
variation and just return the same rate if the clock supported it
(i.e. if the deviation was not that much), but, as mentioned by
Alexey, the clock driver is agnostic of TMDS deviation, its just
a clock driver.
>
>> +return true;
>> +}
> Can't you inline this in arc_pgu_crtc_mode_valid() as there's a single caller
> ?
Yeah, I will in next version. This was a leftover from previous
version where atomic_check() and mode_valid() did the same
validation.
Thanks!
Best regards,
Jose Miguel Abreu
>> static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
>> {
>> struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
>> @@ -64,6 +76,17 @@ static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
>> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
>> };
>>
>> +enum drm_mode_status arc_pgu_crtc_mode_valid(struct drm_crtc *crtc,
>> + const struct drm_display_mode
> *mode)
>> +{
>> +struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
>> +
>> +if (!arc_pgu_is_mode_valid(arcpgu, mode))
>> +return MODE_NOCLOCK;
>> +
>> +return MODE_OK;
>> +}
>> +
>> static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc *crtc)
>> {
>> struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
>> @@ -129,20 +152,6 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
>> ~ARCPGU_CTRL_ENABLE_MASK);
>> }
>>
>> -static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
>> - struct drm_crtc_state *state)
>> -{
>> -struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
>> -struct drm_display_mode *mode = &state
Re: [PATCH net-next] net: stmmac: remove superfluous wmb() memory barriers
Hi Niklas,
On 08-03-2018 10:30, Niklas Cassel wrote:
> These wmb() memory barriers are performed after the last descriptor write,
> and they are followed by enable_dma_transmission()/set_tx_tail_ptr(),
> i.e. a writel() to MMIO register space.
> Since writel() itself performs the equivalent of a wmb()
Sorry but I know at least two architectures which don't do a
wmb() upon an writel [1] [2]. This can be critical if if we are
accessing the device through some slow or filled bus which will
delay accesses to the device IO. Notice that writel and then
readl to the same address will force CPU to wait for writel
completion before readl, but in this case we are using DMA and
then writel so I think a wmb() before the writel is a safe measure.
Thanks and Best Regards,
Jose Miguel Abreu
[1]
https://elixir.bootlin.com/linux/latest/source/arch/arc/include/asm/io.h#L147,
with "CONFIG_ISA_ARCV2=n"
[2]
https://elixir.bootlin.com/linux/latest/source/arch/arm/include/asm/io.h#L314,
with "CONFIG_ARM_DMA_MEM_BUFFERABLE=n"
> before doing the
> actual write, these barriers are superfluous, and removing them should
> thus not change any existing behavior.
>
> Ordering within the descriptor writes is already ensured with dma_wmb()
> barriers inside prepare_tx_desc(first, ..)/prepare_tso_tx_desc(first, ..).
>
> Signed-off-by: Niklas Cassel
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index a9856a8bf8ad..005fb45ace30 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2998,12 +2998,6 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff
> *skb, struct net_device *dev)
> priv->hw->desc->set_tx_owner(mss_desc);
> }
>
> - /* The own bit must be the latest setting done when prepare the
> - * descriptor and then barrier is needed to make sure that
> - * all is coherent before granting the DMA engine.
> - */
> - wmb();
> -
> if (netif_msg_pktdata(priv)) {
> pr_info("%s: curr=%d dirty=%d f=%d, e=%d, f_p=%p, nfrags %d\n",
> __func__, tx_q->cur_tx, tx_q->dirty_tx, first_entry,
> @@ -3221,12 +3215,6 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb,
> struct net_device *dev)
> priv->hw->desc->prepare_tx_desc(first, 1, nopaged_len,
> csum_insertion, priv->mode, 1,
> last_segment, skb->len);
> -
> - /* The own bit must be the latest setting done when prepare the
> - * descriptor and then barrier is needed to make sure that
> - * all is coherent before granting the DMA engine.
> - */
> - wmb();
> }
>
> netdev_tx_sent_queue(netdev_get_tx_queue(dev, queue), skb->len);
Re: [PATCH] ARC: io.h: Implement reads{x}()/writes{x}()
On 29-11-2018 13:03, David Laight wrote:
> From: Jose Abreu [mailto:jose.ab...@synopsys.com]
>> On 29-11-2018 12:47, David Laight wrote:
>>> From: Jose Abreu
>>>> Sent: 29 November 2018 12:42
>>>>
>>>> Some ARC CPU's do not support unaligned loads/stores. Currently, generic
>>>> implementation of reads{b/w/l}()/writes{b/w/l}() is being used with ARC.
>>>> This can lead to misfunction of some drivers as generic functions do a
>>>> plain dereference of a pointer that can be unaligned.
>>>>
>>>> Let's use {get/put}_unaligned() helper instead of plain dereference of
>>>> pointer in order to fix this.
>>> Is it worth adding a check for the pointer being aligned?
>> We could but then we would need to know which CPU version is
>> currently running because some ARC processors support unaligned
>> accesses.
> Eh?
> If the CPU supports unaligned accesses you could patch the code
> to do unaligned accesses.
*Some* ARC CPU versions support unaligned memory access. The one
we tested this on does not support unaligned accesses.
>
> I was thinking of the (probably likely) case where the pointer is
> actually aligned.
> An extra check for ((pointer) & 3) is almost certainly a 'win'
> over the byte accesses and shift/mask/or use by get/put_unaligned().
>
> The IO accesses probably dominate making more complex optimisations
> less likely to have any benefit.
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Registration No: 1397386 (Wales)
[PATCH v2] ARC: io.h: Implement reads{x}()/writes{x}()
Some ARC CPU's do not support unaligned loads/stores. Currently, generic
implementation of reads{b/w/l}()/writes{b/w/l}() is being used with ARC.
This can lead to misfunction of some drivers as generic functions do a
plain dereference of a pointer that can be unaligned.
Let's use {get/put}_unaligned() helper instead of plain dereference of
pointer in order to fix this.
Changes from v1:
- Check if buffer is already aligned (David)
- Remove 64 bit mention (Alexey)
Signed-off-by: Jose Abreu
Tested-by: Vitor Soares
Cc: Vineet Gupta
Cc: Alexey Brodkin
Cc: Joao Pinto
Cc: Vitor Soares
Cc: David Laight
---
arch/arc/include/asm/io.h | 61 +++
1 file changed, 61 insertions(+)
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index c22b181e8206..949759a45cff 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_ISA_ARCV2
#include
@@ -94,6 +95,34 @@ static inline u32 __raw_readl(const volatile void __iomem
*addr)
return w;
}
+#define __raw_readsx(t,f) \
+static inline void __raw_reads##f(const volatile void __iomem *addr, \
+ void *buffer, unsigned int count) \
+{ \
+ if (count) { \
+ const unsigned long bptr = (unsigned long)buffer; \
+ u##t *buf = buffer; \
+\
+ do { \
+ u##t x = __raw_read##f(addr); \
+\
+ /* Some ARC CPU's don't support unaligned accesses */ \
+ if (bptr % ((t) / 8)) { \
+ put_unaligned(x, buf++); \
+ } else { \
+ *buf++ = x; \
+ } \
+ } while (--count); \
+ } \
+}
+
+#define __raw_readsb __raw_readsb
+__raw_readsx(8, b);
+#define __raw_readsw __raw_readsw
+__raw_readsx(16, w);
+#define __raw_readsl __raw_readsl
+__raw_readsx(32, l);
+
#define __raw_writeb __raw_writeb
static inline void __raw_writeb(u8 b, volatile void __iomem *addr)
{
@@ -126,6 +155,32 @@ static inline void __raw_writel(u32 w, volatile void
__iomem *addr)
}
+#define __raw_writesx(t,f) \
+static inline void __raw_writes##f(volatile void __iomem *addr, \
+ const void *buffer, unsigned int count) \
+{ \
+ if (count) { \
+ const unsigned long bptr = (unsigned long)buffer; \
+ const u##t *buf = buffer; \
+\
+ do { \
+ /* Some ARC CPU's don't support unaligned accesses */ \
+ if (bptr % ((t) / 8)) { \
+ __raw_write##f(get_unaligned(buf++), addr); \
+ } else { \
+ __raw_write##f(*buf++, addr); \
+ } \
+ } while (--count); \
+ } \
+}
+
+#define __raw_writesb __raw_writesb
+__raw_writesx(8, b);
+#define __raw_writesw __raw_writesw
+__raw_writesx(16, w);
+#define __raw_writesl __raw_writesl
+__raw_writesx(32, l);
+
/*
* MMIO can also get buffered/optimized in micro-arch, so barriers needed
* Based on ARM model for the typical use case
@@ -141,10 +196,16 @@ static inline void __raw_writel(u32 w, volatile void
__iomem *addr)
#define readb(c) ({ u8 __v = readb_relaxed(c); __iormb(); __v;
})
#define readw(c) ({ u16 __v = readw_relaxed(c); __iormb(); __v;
})
#define readl(c) ({ u32 __v = readl_relaxed(c); __iormb(); __v;
})
+#define readsb(p,d,l) ({ __raw_readsb(p,d,l); __iormb(); })
+#define readsw(p,d,l) ({ __raw_readsw(p,d,l); __iormb(); })
+#define readsl(p,d,l) ({ __raw_readsl(p,d,l); __iormb(); })
#define writeb(v,c)({ __iowmb(); writeb_relaxed(v,c); })
#define writew(v,c)({ __iowmb(); writew_relaxed(v,c); })
#define writel(v,c)({ __iowmb(); writel_relaxed(v,c); })
+#define writesb(p,d,l) ({ __iowmb(); __raw_writesb(p,d,l); })
+#define writesw(p,d,l) ({ __iowmb(); __raw_writesw(p,d,l); })
+#define writesl(p,d,l) ({ __iowmb(); __raw_writesl(p,d,l); })
/*
* Relaxed API for drivers which can handle barrier ordering themselves
--
2.7.4
Re: [PATCH v2] ARC: io.h: Implement reads{x}()/writes{x}()
On 29-11-2018 14:38, David Laight wrote:
> From: Jose Abreu
>> Sent: 29 November 2018 14:29
>>
>> Some ARC CPU's do not support unaligned loads/stores. Currently, generic
>> implementation of reads{b/w/l}()/writes{b/w/l}() is being used with ARC.
>> This can lead to misfunction of some drivers as generic functions do a
>> plain dereference of a pointer that can be unaligned.
>>
>> Let's use {get/put}_unaligned() helper instead of plain dereference of
>> pointer in order to fix this.
> ...
>> +#define __raw_readsx(t,f) \
>> +static inline void __raw_reads##f(const volatile void __iomem *addr, \
>> + void *buffer, unsigned int count) \
>> +{ \
>> +if (count) { \
>> +const unsigned long bptr = (unsigned long)buffer; \
>> +u##t *buf = buffer; \
>> +\
>> +do { \
>> +u##t x = __raw_read##f(addr); \
>> +\
>> +/* Some ARC CPU's don't support unaligned accesses */ \
>> +if (bptr % ((t) / 8)) { \
>> +put_unaligned(x, buf++); \
>> +} else { \
>> +*buf++ = x; \
>> +} \
>> +} while (--count); \
>> +} \
>> +}
> Does the compiler move the alignment test outside the loop?
> You really want two copies of the loop body.
Hmm, I would expect so because the if condition takes two const
args ... I will try check that.
Thanks and Best Regards,
Jose Miguel Abreu
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Registration No: 1397386 (Wales)
>
Re: [PATCH v2] ARC: io.h: Implement reads{x}()/writes{x}()
On 29-11-2018 14:42, Jose Abreu wrote:
> On 29-11-2018 14:38, David Laight wrote:
>> From: Jose Abreu
>>> Sent: 29 November 2018 14:29
>>>
>>> Some ARC CPU's do not support unaligned loads/stores. Currently, generic
>>> implementation of reads{b/w/l}()/writes{b/w/l}() is being used with ARC.
>>> This can lead to misfunction of some drivers as generic functions do a
>>> plain dereference of a pointer that can be unaligned.
>>>
>>> Let's use {get/put}_unaligned() helper instead of plain dereference of
>>> pointer in order to fix this.
>> ...
>>> +#define __raw_readsx(t,f) \
>>> +static inline void __raw_reads##f(const volatile void __iomem *addr, \
>>> + void *buffer, unsigned int count) \
>>> +{ \
>>> + if (count) { \
>>> + const unsigned long bptr = (unsigned long)buffer; \
>>> + u##t *buf = buffer; \
>>> +\
>>> + do { \
>>> + u##t x = __raw_read##f(addr); \
>>> +\
>>> + /* Some ARC CPU's don't support unaligned accesses */ \
>>> + if (bptr % ((t) / 8)) { \
>>> + put_unaligned(x, buf++); \
>>> + } else { \
>>> + *buf++ = x; \
>>> + } \
>>> + } while (--count); \
>>> + } \
>>> +}
>> Does the compiler move the alignment test outside the loop?
>> You really want two copies of the loop body.
> Hmm, I would expect so because the if condition takes two const
> args ... I will try check that.
And it did optimize :)
Sample C Source:
--->8--
static noinline void test_readsl(char *buf, int len)
{
readsl(0xdeadbeef, buf, len);
}
--->8---
And the disassembly:
--->8---
0e88 :
e88:breq.dr1,0,eac <0xeac>/* if (count) */
e8c:and r2,r0,3
e90:mov_s lp_count,r1/* r1 = count */
e92:brne r2,0,eb0 <0xeb0>/* if (bptr % ((t) / 8)) */
e96:sub r0,r0,4
e9a:nop_s
e9c:lp eac <0xeac>/* first loop */
ea0:ld r2,[0xdeadbeef]
ea8:st.a r2,[r0,4]
eac:j_s [blink]
eae:nop_s
eb0:lp ed6 <0xed6>/* second loop */
eb4:ld r2,[0xdeadbeef]
ebc:lsr r5,r2,8
ec0:lsr r4,r2,16
ec4:lsr r3,r2,24
ec8:stb_s r2,[r0,0]
eca:stb r5,[r0,1]
ece:stb r4,[r0,2]
ed2:stb_s r3,[r0,3]
ed4:add_s r0,r0,4
ed6:j_s [blink]
--->8---
See how the if condition added in this version is checked in
and then it takes two different loops.
Thanks and Best Regards,
Jose Miguel Abreu
>
> Thanks and Best Regards,
> Jose Miguel Abreu
>
>> David
>>
>> -
>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
>> 1PT, UK
>> Registration No: 1397386 (Wales)
>>
Re: [BUG] net: stmmac: dwmac-sun8i broken in linux-next
Hi Corentin,
On 16-05-2018 19:32, Corentin Labbe wrote:
> Hello
>
> The dwmac-sun8i driver is broken in next-20180515, symptom are no RX and TX
> errors as shown by ifconfig:
> eth0: flags=4163 mtu 1500
> inet 192.168.1.204 netmask 255.255.255.0 broadcast 192.168.1.255
> ether 96:75:ff:0d:f6:d8 txqueuelen 1000 (Ethernet)
> RX packets 0 bytes 0 (0.0 B)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 0 bytes 4956 (4.8 KiB)
> TX errors 118 dropped 0 overruns 0 carrier 0 collisions 0
>
> Reverting the following commit made the driver working:
> 4dbbe8dde8485b89bce8bbbe7564337fd7eed69f ("net: stmmac: Add support for U32
> TC filter using Flexible RX Parser")
> 5f0456b43140af9413397cc11d03d18b9f2fc2fc ("net: stmmac: Implement logic to
> automatically select HW Interface")
>
> Note that reverting only 4dbbe8dde8485b89bce8bbbe7564337fd7eed69f lead to
> crash:
> [ 31.385110] Backtrace:
> [ 31.387576] [] (stmmac_open) from []
> (__dev_open+0xe4/0x180)
> [ 31.394972] r10:ed447d04 r9:edc5d010 r8:ef02002c r7:c08670a4 r6:
> r5:c0c08488
> [ 31.402793] r4:ef02
> [ 31.405335] [] (__dev_open) from []
> (__dev_change_flags+0x190/0x1e8)
> [ 31.413421] r8:1002 r7:c0c08488 r6:1003 r5:0001 r4:ef02
> [ 31.420122] [] (__dev_change_flags) from []
> (dev_change_flags+0x20/0x50)
> [ 31.428555] r9:edc5d010 r8:ed447c18 r7:ef020134 r6: r5:1002
> r4:ef02
> [ 31.436300] [] (dev_change_flags) from []
> (do_setlink+0x28c/0xbdc)
> [ 31.444213] r9:edc5d010 r8:ed447c18 r7: r6:c0c08488 r5:ed447b50
> r4:ef02
> [ 31.451955] [] (do_setlink) from []
> (rtnl_newlink+0x54c/0x7a8)
> [ 31.459522] r10:ed447d04 r9: r8: r7: r6:
> r5:
> [ 31.467343] r4:ef02
> [ 31.469885] [] (rtnl_newlink) from []
> (rtnetlink_rcv_msg+0x38c/0x544)
> [ 31.478058] r10:ed447d04 r9: r8:ee242840 r7: r6:edc5d000
> r5:c0c08488
> [ 31.485879] r4:
> [ 31.488422] [] (rtnetlink_rcv_msg) from []
> (netlink_rcv_skb+0xc0/0x118)
> [ 31.496768] r10:c0c08488 r9: r8:0020 r7:edc5d000 r6:c064466c
> r5:c0c08488
> [ 31.504589] r4:ee242840
> [ 31.507129] [] (netlink_rcv_skb) from []
> (rtnetlink_rcv+0x18/0x1c)
> [ 31.515042] r8:ed447d60 r7:ee242840 r6:0020 r5:ee37d800 r4:ee5fac00
> [ 31.521742] [] (rtnetlink_rcv) from []
> (netlink_unicast+0x190/0x1fc)
> [ 31.529829] [] (netlink_unicast) from []
> (netlink_sendmsg+0x3cc/0x410)
> [ 31.538089] r10: r9:0020 r8:014000c0 r7:ee242840 r6:ee37d800
> r5:c0c08488
> [ 31.545910] r4:ed447f44
> [ 31.548452] [] (netlink_sendmsg) from []
> (sock_sendmsg+0x1c/0x2c)
> [ 31.556279] r10: r9:ed447edc r8: r7:eefce640 r6:
> r5:c0c08488
> [ 31.564100] r4:ed447f44
> [ 31.566640] [] (sock_sendmsg) from []
> (___sys_sendmsg+0x250/0x264)
> [ 31.574555] [] (___sys_sendmsg) from []
> (__sys_sendmsg+0x58/0x94)
> [ 31.582382] r10: r9:ed446000 r8:c01011c4 r7:eefce640 r6:
> r5:bec25150
> [ 31.590203] r4:c0c08488
> [ 31.592743] [] (__sys_sendmsg) from []
> (sys_sendmsg+0x14/0x18)
> [ 31.600307] r7:0128 r6:bec2d17c r5:bec25144 r4:00093ee0
> [ 31.605969] [] (sys_sendmsg) from []
> (ret_fast_syscall+0x0/0x28)
> [ 31.613704] Exception stack(0xed447fa8 to 0xed447ff0)
> [ 31.618756] 7fa0: 00093ee0 bec25144 0003 bec25150
> 85ce
> [ 31.626929] 7fc0: 00093ee0 bec25144 bec2d17c 0128 000942a8 5afc783a
> 00094000 bec25150
> [ 31.635099] 7fe0: bec250f0 012c b6e10b5c
> [ 31.640152] Code: e59a261c e59a013c e50b306c e592300c (e593300c)
> [ 31.646632] ---[ end trace 407964b7deb937bf ]---
>
> For the moment, I stil didnt find the issue.
> What to we do now ? do you want that I send revert patchs ?
No need for revert. I checked the patch and dwmac-sun8i
implementation and I think I found the problem. I will send you a
patch to test.
Thanks and Best Regards,
Jose Miguel Abreu
>
> Regards
Re: [PATCH] net: stmmac: Avoid VLA usage
Hi Kees, On 01-05-2018 22:01, Kees Cook wrote: > In the quest to remove all stack VLAs from the kernel[1], this switches > the "status" stack buffer to use the existing small (8) upper bound on > how many queues can be checked for DMA, and adds a sanity-check just to > make sure it doesn't operate under pathological conditions. > > [1] > https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_CA-2B55aFzCG-2DzNmZwX4A2FQpadafLfEzK6CC-3DqPXydAacU1RqZWA-40mail.gmail.com&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=TBD6a7UY2VbpPmV9LOW_eHAyg8uPq1ZPDhq93VROTVE&s=4fvOST1HhWmZ4lThQe-dHCJYEXNOwey00BCXOWm8tKo&e= > > Signed-off-by: Kees Cook > I rather prefer the variables declaration in reverse-tree order, but thats just a minor pick. Reviewed-by: Jose Abreu Thanks and Best Regards, Jose Miguel Abreu PS: Is VLA warning switch in gcc already active? Because I didn't see this warning in my builds.
Re: [PATCH] net: stmmac: Avoid VLA usage
On 02-05-2018 13:36, Kees Cook wrote: > On Wed, May 2, 2018 at 1:54 AM, Jose Abreu wrote: >> Hi Kees, >> >> On 01-05-2018 22:01, Kees Cook wrote: >>> In the quest to remove all stack VLAs from the kernel[1], this switches >>> the "status" stack buffer to use the existing small (8) upper bound on >>> how many queues can be checked for DMA, and adds a sanity-check just to >>> make sure it doesn't operate under pathological conditions. >>> >>> [1] >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_CA-2B55aFzCG-2DzNmZwX4A2FQpadafLfEzK6CC-3DqPXydAacU1RqZWA-40mail.gmail.com&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=TBD6a7UY2VbpPmV9LOW_eHAyg8uPq1ZPDhq93VROTVE&s=4fvOST1HhWmZ4lThQe-dHCJYEXNOwey00BCXOWm8tKo&e= >>> >>> Signed-off-by: Kees Cook >>> >> I rather prefer the variables declaration in reverse-tree order, >> but thats just a minor pick. > I can explicitly reorder the other variables, if you want? No need by me, unless Giuseppe or Alexandre prefer that. Thanks! Best Regards, Jose Miguel Abreu > >> Reviewed-by: Jose Abreu > Thanks! > >> PS: Is VLA warning switch in gcc already active? Because I didn't >> see this warning in my builds. > It is not. A bunch of people have been building with KCFLAGS=-Wvla to > find the VLAs and sending patches. Once we get rid of them all, we can > add the flag to the top-level Makefile. > > -Kees >
Re: [PATCH net-next v2 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()
On 16-05-2018 00:56, Florian Fainelli wrote: > A number of drivers have the following pattern: > > if (np) > of_mdiobus_register() > else > mdiobus_register() > > which the implementation of of_mdiobus_register() now takes care of. > Remove that pattern in drivers that strictly adhere to it. > > Signed-off-by: Florian Fainelli > --- > drivers/net/dsa/bcm_sf2.c | 8 ++-- > drivers/net/dsa/mv88e6xxx/chip.c | 5 + > drivers/net/ethernet/cadence/macb_main.c | 12 +++- > drivers/net/ethernet/freescale/fec_main.c | 8 ++-- > drivers/net/ethernet/marvell/mvmdio.c | 5 + > drivers/net/ethernet/renesas/sh_eth.c | 11 +++ > drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 5 + For stmmac: Reviewed-by: Jose Abreu Thanks and Best Regards, Jose Miguel Abreu > drivers/net/ethernet/ti/davinci_mdio.c| 8 +++- > drivers/net/phy/mdio-gpio.c | 6 +- > drivers/net/phy/mdio-mscc-miim.c | 6 +- > drivers/net/usb/lan78xx.c | 7 ++- > 11 files changed, 20 insertions(+), 61 deletions(-) >
Re: [PATCH] net: dwc-xlgmac: fix xlgmac_xmit()'s return type
On 24-04-2018 14:17, Luc Van Oostenryck wrote: > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, but the implementation in this > driver returns an 'int'. > > Fix this by returning 'netdev_tx_t' in this driver too. > > Signed-off-by: Luc Van Oostenryck > --- I wouldn't do this because of at least two reasons: - xlgmac_xmit() calls xlgmac_maybe_stop_tx_queue() and xlgmac_prep_tso(), and this last one can return a negative error code. I expect some others drivers to have similar behavior. - If you look along net subsystem you will see that this enum is directly converted to an int in later stages. So, and given that you sent a large number of patches about this, perhaps it would be more clear to change the function definition? Thanks and Best Regards, Jose Miguel Abreu
[PATCH net 0/2] Use C45 Helpers when possible
For -net. Please review! Cc: Andrew Lunn Cc: Florian Fainelli Cc: "David S. Miller" Cc: Joao Pinto Jose Abreu (2): net: phy: Use C45 Helpers in phy_read_status() net: phy: Use C45 Helpers in PHY_FORCING state drivers/net/phy/phy.c | 2 +- include/linux/phy.h | 15 +++ 2 files changed, 16 insertions(+), 1 deletion(-) -- 2.7.4
[PATCH net 1/2] net: phy: Use C45 Helpers in phy_read_status()
Currently phy_read_status() considers that either the PHY driver has the read_status() callback or uses the generic callback. For C45 PHYs we need to use the gen10g_read_status() callback. Signed-off-by: Jose Abreu Cc: Andrew Lunn Cc: Florian Fainelli Cc: "David S. Miller" Cc: Joao Pinto --- include/linux/phy.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/phy.h b/include/linux/phy.h index 333b56d8f746..872899136fdc 100644 --- a/include/linux/phy.h +++ b/include/linux/phy.h @@ -1030,6 +1030,8 @@ static inline int phy_read_status(struct phy_device *phydev) if (phydev->drv->read_status) return phydev->drv->read_status(phydev); + else if (phydev->is_c45) + return gen10g_read_status(phydev); else return genphy_read_status(phydev); } -- 2.7.4
[PATCH net 2/2] net: phy: Use C45 Helpers in PHY_FORCING state
When using a C45 PHY that is in PHY_FORCING state we are currently not
taking into account that this kind of PHY has different update_link
functions.
Use the C45 Helpers instead or the driver built-in read_status() helper,
if possible.
Signed-off-by: Jose Abreu
Cc: Andrew Lunn
Cc: Florian Fainelli
Cc: "David S. Miller"
Cc: Joao Pinto
---
drivers/net/phy/phy.c | 2 +-
include/linux/phy.h | 13 +
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index c5675df5fc6f..1ef5dbc384d0 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -940,7 +940,7 @@ void phy_state_machine(struct work_struct *work)
err = phy_check_link_status(phydev);
break;
case PHY_FORCING:
- err = genphy_update_link(phydev);
+ err = phy_update_link(phydev);
if (err)
break;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 872899136fdc..67caa7eb93b1 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1036,6 +1036,19 @@ static inline int phy_read_status(struct phy_device
*phydev)
return genphy_read_status(phydev);
}
+static inline int phy_update_link(struct phy_device *phydev)
+{
+ if (!phydev->drv)
+ return -EIO;
+
+ if (phydev->drv->read_status)
+ return phydev->drv->read_status(phydev);
+ else if (phydev->is_c45)
+ return gen10g_read_status(phydev);
+ else
+ return genphy_update_link(phydev);
+}
+
void phy_driver_unregister(struct phy_driver *drv);
void phy_drivers_unregister(struct phy_driver *drv, int n);
int phy_driver_register(struct phy_driver *new_driver, struct module *owner);
--
2.7.4
RE: [PATCH 0/7] net: stmmac: enable EHL SGMII
From: Weifeng Voon Date: Wed, Apr 24, 2019 at 18:17:14 > From: "Voon, Weifeng" > > This patch-set is to enable Ethernet controller (DW Ethernet QoS > and DW Ethernet PCS) with SGMII interface in Elkhart Lake. The > DW Ethernet PCS is the Physical Coding Sublayer that is between > Ethernet MAC and PHY and uses MDIO Clause-45 as Communication. > Please re-send this series with the stmmac maintainers in CC. Also CC Andrew Lunn and Florian Fainelli for the C45 part. Thanks, Jose Miguel Abreu
RE: [PATCH] reset: axs10x: Implement assert and deassert callbacks
From: Vitor Soares
Date: Mon, Apr 08, 2019 at 11:31:23
> static const struct reset_control_ops axs10x_reset_ops = {
> - .reset = axs10x_reset_reset,
Eugeniy, Alexey,
I think the implementation of this callback is wrong: you should
readl_poll_timeout_atomic() until the reset bit is not cleared.
Thanks,
Jose Miguel Abreu
Re: [PATCH 1/2 v6] ASoC: dwc: Add custom PCM driver
Hi Mark,
Can you give me some comments regarding this patch? Am I following the right
track? This is the first time that I am using ALSA SoC so pardon me if I am
making some mistake. I would appreciate some kind of input. I tested this only
on a ARC SDP and it is working.
On 27-04-2016 11:05, Jose Abreu wrote:
> HDMI audio support was added to the AXS board using an
> I2S cpu driver and a custom platform driver.
>
> The platform driver supports two channels @ 16 bits with
> rates 32k, 44.1k and 48k.
>
> Although the mainline I2S driver uses ALSA DMA engine,
> this controller can be built without DMA support so it
> was necessary to add this custom platform driver so that
> HDMI audio works in AXS boards.
>
> The selection between the use of DMA engine or PIO mode
> is detected by declaring or not the DMA parameters in
> the device tree.
>
> Signed-off-by: Jose Abreu
> Cc: Carlos Palminha
> Cc: Mark Brown
> Cc: Liam Girdwood
> Cc: Jaroslav Kysela
> Cc: Takashi Iwai
> Cc: Alexey Brodkin
> Cc: linux-snps-...@lists.infradead.org
> Cc: alsa-de...@alsa-project.org
> Cc: linux-kernel@vger.kernel.org
> ---
>
> Changes v5 -> v6:
> * Use SNDRV_DMA_TYPE_CONTINUOUS
>
> Changes v4 -> v5:
> * Resolve undefined references when compiling as module
> * Use DMA properties in I2S to check which mode to use: PIO or DMA (as
> suggested by Lars-Peter Clausen)
>
> Changes v3 -> v4:
> * Reintroduced custom PCM driver
> * Use DT boolean to switch between ALSA DMA engine PCM or custom PCM
>
> Changes v2 -> v3:
> * Removed pll_config functions (as suggested by Alexey Brodkin)
> * Dropped custom platform driver, using now ALSA DMA engine
> * Dropped IRQ handler for I2S
>
> No changes v1 -> v2.
>
> sound/soc/dwc/Kconfig | 9 ++
> sound/soc/dwc/Makefile | 1 +
> sound/soc/dwc/designware.h | 71 +
> sound/soc/dwc/designware_i2s.c | 94 -
> sound/soc/dwc/designware_pcm.c | 228
> +
> 5 files changed, 376 insertions(+), 27 deletions(-)
> create mode 100644 sound/soc/dwc/designware.h
> create mode 100644 sound/soc/dwc/designware_pcm.c
>
> diff --git a/sound/soc/dwc/Kconfig b/sound/soc/dwc/Kconfig
> index d50e085..2a21120 100644
> --- a/sound/soc/dwc/Kconfig
> +++ b/sound/soc/dwc/Kconfig
> @@ -7,4 +7,13 @@ config SND_DESIGNWARE_I2S
>Synopsys desigwnware I2S device. The device supports upto
>maximum of 8 channels each for play and record.
>
> +config SND_DESIGNWARE_PCM
> + tristate "Synopsys I2S PCM Driver"
> + help
> + Say Y or M if you want to add support for ALSA ASoC platform driver
> + using I2S.
> +
> + Select this option if you want to be able to create a sound interface
> + using the I2S device driver as CPU driver. Instead of using ALSA
> + DMA engine by selecting this driver a custom PCM driver will be used.
>
> diff --git a/sound/soc/dwc/Makefile b/sound/soc/dwc/Makefile
> index 319371f..1b48bccc 100644
> --- a/sound/soc/dwc/Makefile
> +++ b/sound/soc/dwc/Makefile
> @@ -1,3 +1,4 @@
> # SYNOPSYS Platform Support
> obj-$(CONFIG_SND_DESIGNWARE_I2S) += designware_i2s.o
> +obj-$(CONFIG_SND_DESIGNWARE_PCM) += designware_pcm.o
>
> diff --git a/sound/soc/dwc/designware.h b/sound/soc/dwc/designware.h
> new file mode 100644
> index 000..09fafee
> --- /dev/null
> +++ b/sound/soc/dwc/designware.h
> @@ -0,0 +1,71 @@
> +/*
> + * ALSA SoC Synopsys Audio Layer
> + *
> + * sound/soc/dwc/designware.h
> + *
> + * Copyright (C) 2016 Synopsys
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __DESIGNWARE_H
> +#define __DESIGNWARE_H
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct dw_pcm_binfo {
> + struct snd_pcm_substream *stream;
> + unsigned char *dma_base;
> + unsigned char *dma_pointer;
> + unsigned int period_size_frames;
> + unsigned int size;
> + snd_pcm_uframes_t period_pointer;
> + unsigned int total_periods;
> + unsigned int current_period;
> +};
> +
> +union dw_i2s_snd_dma_data {
> + struct i2s_dma_data pd;
> + struct snd_dmaengine_dai_dma_data dt;
> +};
> +
> +struct dw_i2s_dev {
> + void __iomem *i2s_base;
> + struct clk *clk;
> + int active;
> + unsigned int capability;
> + unsigned int quirks;
> + unsigned int i2s_reg_comp1;
> + unsigned int i2s_reg_comp2;
> +
[RESEND PATCH 0/2 v6] Add AXS10X I2S PLL clock driver
The ARC SDP I2S clock can be programmed using a
specific PLL.
This patch series has the goal of adding a clock driver
that programs this PLL.
Changes v5 -> v6:
* Use parent clock to determine PLL input rate instead of using hardcoded values
* Documentation update (added 'clocks' field)
* Device tree update (added 'clocks' field)
Changes v4 -> v5:
* Documentation update (as suggested by Alexey Brodkin)
* Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by
Alexey Brodkin)
* Added DT bindings
Changes v3 -> v4:
* Added binding document (as suggested by Stephen Boyd)
* Minor code style fixes (as suggested by Stephen Boyd)
* Use ioremap (as suggested by Stephen Boyd)
* Implement round_rate (as suggested by Stephen Boyd)
* Change to platform driver (as suggested by Stephen Boyd)
* Use {readl/writel}_relaxed (as suggested by Vineet Gupta)
Changes v2 -> v3:
* Implemented recalc_rate
Changes v1 -> v2:
* Renamed folder to axs10x (as suggested by Alexey Brodkin)
* Added more supported rates
Cc: Carlos Palminha
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Alexey Brodkin
Cc: Vineet Gupta
Cc: linux-snps-...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Jose Abreu (2):
clk/axs10x: Add I2S PLL clock driver
arc: axs10x: Add DT bindings for I2S PLL Clock
.../bindings/clock/axs10x-i2s-pll-clock.txt| 25 +++
arch/arc/boot/dts/axs10x_mb.dtsi | 13 ++
drivers/clk/Makefile | 1 +
drivers/clk/axs10x/Makefile| 1 +
drivers/clk/axs10x/i2s_pll_clock.c | 228 +
5 files changed, 268 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
create mode 100644 drivers/clk/axs10x/Makefile
create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c
--
1.9.1
[RESEND PATCH 1/2 v6] clk/axs10x: Add I2S PLL clock driver
The ARC SDP I2S clock can be programmed using a
specific PLL.
This patch has the goal of adding a clock driver
that programs this PLL.
At this moment the rate values are hardcoded in
a table but in the future it would be ideal to
use a function which determines the PLL values
given the desired rate.
Signed-off-by: Jose Abreu
---
Changes v5 -> v6:
* Use parent clock to determine PLL input rate instead of using hardcoded values
* Documentation update (added 'clocks' field)
Changes v4 -> v5:
* Documentation update (as suggested by Alexey Brodkin)
* Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by
Alexey Brodkin)
Changes v3 -> v4:
* Added binding document (as suggested by Stephen Boyd)
* Minor code style fixes (as suggested by Stephen Boyd)
* Use ioremap (as suggested by Stephen Boyd)
* Implement round_rate (as suggested by Stephen Boyd)
* Change to platform driver (as suggested by Stephen Boyd)
* Use {readl/writel}_relaxed (as suggested by Vineet Gupta)
Changes v2 -> v3:
* Implemented recalc_rate
Changes v1 -> v2:
* Renamed folder to axs10x (as suggested by Alexey Brodkin)
* Added more supported rates
Cc: Carlos Palminha
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Alexey Brodkin
Cc: Vineet Gupta
Cc: linux-snps-...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
.../bindings/clock/axs10x-i2s-pll-clock.txt| 25 +++
drivers/clk/Makefile | 1 +
drivers/clk/axs10x/Makefile| 1 +
drivers/clk/axs10x/i2s_pll_clock.c | 228 +
4 files changed, 255 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
create mode 100644 drivers/clk/axs10x/Makefile
create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c
diff --git a/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
new file mode 100644
index 000..5ffc8df
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
@@ -0,0 +1,25 @@
+Binding for the AXS10X I2S PLL clock
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible: shall be "snps,axs10x-i2s-pll-clock"
+- reg : address and length of the I2S PLL register set.
+- clocks: shall be the input parent clock phandle for the PLL.
+- #clock-cells: from common clock binding; Should always be set to 0.
+
+Example:
+ pll_clock: pll_clock {
+ compatible = "fixed-clock";
+ clock-frequency = <2700>;
+ #clock-cells = <0>;
+ };
+
+ i2s_clock@100a0 {
+ compatible = "snps,axs10x-i2s-pll-clock";
+ reg = <0x100a0 0x10>;
+ clocks = <&pll_clock>;
+ #clock-cells = <0>;
+ };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 46869d6..2ca62dc6 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -84,3 +84,4 @@ obj-$(CONFIG_X86) += x86/
obj-$(CONFIG_ARCH_ZX) += zte/
obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
obj-$(CONFIG_H8300)+= h8300/
+obj-$(CONFIG_ARC_PLAT_AXS10X) += axs10x/
diff --git a/drivers/clk/axs10x/Makefile b/drivers/clk/axs10x/Makefile
new file mode 100644
index 000..01996b8
--- /dev/null
+++ b/drivers/clk/axs10x/Makefile
@@ -0,0 +1 @@
+obj-y += i2s_pll_clock.o
diff --git a/drivers/clk/axs10x/i2s_pll_clock.c
b/drivers/clk/axs10x/i2s_pll_clock.c
new file mode 100644
index 000..411310d
--- /dev/null
+++ b/drivers/clk/axs10x/i2s_pll_clock.c
@@ -0,0 +1,228 @@
+/*
+ * Synopsys AXS10X SDP I2S PLL clock driver
+ *
+ * Copyright (C) 2016 Synopsys
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* PLL registers addresses */
+#define PLL_IDIV_REG 0x0
+#define PLL_FBDIV_REG 0x4
+#define PLL_ODIV0_REG 0x8
+#define PLL_ODIV1_REG 0xC
+
+struct i2s_pll_cfg {
+ unsigned int rate;
+ unsigned int idiv;
+ unsigned int fbdiv;
+ unsigned int odiv0;
+ unsigned int odiv1;
+};
+
+static const struct i2s_pll_cfg i2s_pll_cfg_27m[] = {
+ /* 27 Mhz */
+ { 1024000, 0x104, 0x451, 0x10E38, 0x2000 },
+ { 1411200, 0x104, 0x596, 0x10D35, 0x2000 },
+ { 1536000, 0x208, 0xA28, 0x10B2C, 0x2000 },
+ { 2048000, 0x82, 0x451, 0x10E38, 0x2000 },
+ { 2822400, 0x82, 0x596, 0x10D35,
[RESEND PATCH 2/2 v6] arc: axs10x: Add DT bindings for I2S PLL Clock
Add device tree bindings for AXS10X I2S PLL Clock driver.
Signed-off-by: Jose Abreu
Acked-by: Alexey Brodkin
Acked-by: Vineet Gupta
---
Changes v5 -> v6:
* Added 'clocks' field
This patch was only introduced in v5.
Cc: Carlos Palminha
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Alexey Brodkin
Cc: Vineet Gupta
Cc: linux-snps-...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
arch/arc/boot/dts/axs10x_mb.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index ab5d570..5c6489e 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -16,7 +16,20 @@
ranges = <0x 0xe000 0x1000>;
interrupt-parent = <&mb_intc>;
+ i2sclk: i2sclk@100a0 {
+ compatible = "snps,axs10x-i2s-pll-clock";
+ reg = <0x100a0 0x10>;
+ clocks = <&i2spll_clk>;
+ #clock-cells = <0>;
+ };
+
clocks {
+ i2spll_clk: i2spll_clk {
+ compatible = "fixed-clock";
+ clock-frequency = <2700>;
+ #clock-cells = <0>;
+ };
+
i2cclk: i2cclk {
compatible = "fixed-clock";
clock-frequency = <5000>;
--
1.9.1
Re: [RESEND PATCH 2/2 v6] arc: axs10x: Add DT bindings for I2S PLL Clock
Hi Vineet,
On 02-05-2016 10:39, Jose Abreu wrote:
> Add device tree bindings for AXS10X I2S PLL Clock driver.
>
> Signed-off-by: Jose Abreu
> Acked-by: Alexey Brodkin
> Acked-by: Vineet Gupta
> ---
>
> Changes v5 -> v6:
> * Added 'clocks' field
>
> This patch was only introduced in v5.
>
> Cc: Carlos Palminha
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar Gala
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: Alexey Brodkin
> Cc: Vineet Gupta
> Cc: linux-snps-...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org
>
> arch/arc/boot/dts/axs10x_mb.dtsi | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi
> b/arch/arc/boot/dts/axs10x_mb.dtsi
> index ab5d570..5c6489e 100644
> --- a/arch/arc/boot/dts/axs10x_mb.dtsi
> +++ b/arch/arc/boot/dts/axs10x_mb.dtsi
> @@ -16,7 +16,20 @@
> ranges = <0x 0xe000 0x1000>;
> interrupt-parent = <&mb_intc>;
>
> + i2sclk: i2sclk@100a0 {
> + compatible = "snps,axs10x-i2s-pll-clock";
> + reg = <0x100a0 0x10>;
> + clocks = <&i2spll_clk>;
> + #clock-cells = <0>;
> + };
> +
> clocks {
> + i2spll_clk: i2spll_clk {
> + compatible = "fixed-clock";
> + clock-frequency = <2700>;
> + #clock-cells = <0>;
> + };
> +
> i2cclk: i2cclk {
> compatible = "fixed-clock";
> clock-frequency = <5000>;
Can you apply this to arc-next? Main driver was already merged into clk-next. We
still have to check how to deal with the parent clock frequency that will change
in the next firmware release.
Best regards,
Jose Miguel Abreu
[PATCH 3/4 v7] ASoC: dwc: Add PIO PCM extension
A PCM extension was added to I2S driver so that audio samples are transferred using PIO mode. The PCM supports two channels @ 16 or 32 bits with rates 32k, 44.1k and 48k. Although the mainline I2S driver uses ALSA DMA engine the I2S controller can be built without DMA support, therefore this is the reason why this extension was added. The selection between the use of DMA engine or PIO mode is detected by declaring or not the interrupt parameters in the DT and using Kconfig. Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: Mark Brown Cc: Liam Girdwood Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Rob Herring Cc: Alexey Brodkin Cc: linux-snps-...@lists.infradead.org Cc: alsa-de...@alsa-project.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- Changes v6 -> v7: * Discard the use of memcpy * Report IRQ_HANDLED only when there is an IRQ * Use interrupts to check if PIO mode is in use * Unmask interrupts only when in PIO mode * Remove empty functions Changes v5 -> v6: * Use SNDRV_DMA_TYPE_CONTINUOUS Changes v4 -> v5: * Resolve undefined references when compiling as module * Use DMA properties in I2S to check which mode to use: PIO or DMA (as suggested by Lars-Peter Clausen) Changes v3 -> v4: * Reintroduced custom PCM driver * Use DT boolean to switch between ALSA DMA engine PCM or custom PCM Changes v2 -> v3: * Removed pll_config functions (as suggested by Alexey Brodkin) * Dropped custom platform driver, using now ALSA DMA engine * Dropped IRQ handler for I2S No changes v1 -> v2. sound/soc/dwc/Kconfig | 9 ++ sound/soc/dwc/Makefile | 5 +- sound/soc/dwc/designware_i2s.c | 148 --- sound/soc/dwc/designware_pcm.c | 220 + sound/soc/dwc/local.h | 122 +++ 5 files changed, 415 insertions(+), 89 deletions(-) create mode 100644 sound/soc/dwc/designware_pcm.c create mode 100644 sound/soc/dwc/local.h diff --git a/sound/soc/dwc/Kconfig b/sound/soc/dwc/Kconfig index d50e085..c6fd95f 100644 --- a/sound/soc/dwc/Kconfig +++ b/sound/soc/dwc/Kconfig @@ -7,4 +7,13 @@ config SND_DESIGNWARE_I2S Synopsys desigwnware I2S device. The device supports upto maximum of 8 channels each for play and record. +config SND_DESIGNWARE_PCM + bool "PCM PIO extension for I2S driver" + depends on SND_DESIGNWARE_I2S + help +Say Y or N if you want to add a custom ALSA extension that registers +a PCM and uses PIO to transfer data. + +This functionality is specially suited for I2S devices that don't have +DMA support. diff --git a/sound/soc/dwc/Makefile b/sound/soc/dwc/Makefile index 319371f..11ea966 100644 --- a/sound/soc/dwc/Makefile +++ b/sound/soc/dwc/Makefile @@ -1,3 +1,4 @@ # SYNOPSYS Platform Support -obj-$(CONFIG_SND_DESIGNWARE_I2S) += designware_i2s.o - +obj-$(CONFIG_SND_DESIGNWARE_I2S) += dwc_i2s.o +dwc_i2s-y := designware_i2s.o +dwc_i2s-$(CONFIG_SND_DESIGNWARE_PCM) += designware_pcm.o diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c index a97be8e..d4c3811 100644 --- a/sound/soc/dwc/designware_i2s.c +++ b/sound/soc/dwc/designware_i2s.c @@ -24,90 +24,7 @@ #include #include #include - -/* common register for all channel */ -#define IER0x000 -#define IRER 0x004 -#define ITER 0x008 -#define CER0x00C -#define CCR0x010 -#define RXFFR 0x014 -#define TXFFR 0x018 - -/* I2STxRxRegisters for all channels */ -#define LRBR_LTHR(x) (0x40 * x + 0x020) -#define RRBR_RTHR(x) (0x40 * x + 0x024) -#define RER(x) (0x40 * x + 0x028) -#define TER(x) (0x40 * x + 0x02C) -#define RCR(x) (0x40 * x + 0x030) -#define TCR(x) (0x40 * x + 0x034) -#define ISR(x) (0x40 * x + 0x038) -#define IMR(x) (0x40 * x + 0x03C) -#define ROR(x) (0x40 * x + 0x040) -#define TOR(x) (0x40 * x + 0x044) -#define RFCR(x)(0x40 * x + 0x048) -#define TFCR(x)(0x40 * x + 0x04C) -#define RFF(x) (0x40 * x + 0x050) -#define TFF(x) (0x40 * x + 0x054) - -/* I2SCOMPRegisters */ -#define I2S_COMP_PARAM_2 0x01F0 -#define I2S_COMP_PARAM_1 0x01F4 -#define I2S_COMP_VERSION 0x01F8 -#define I2S_COMP_TYPE 0x01FC - -/* - * Component parameter register fields - define the I2S block's - * configuration. - */ -#defineCOMP1_TX_WORDSIZE_3(r) (((r) & GENMASK(27, 25)) >> 25) -#defineCOMP1_TX_WORDSIZE_2(r) (((r) & GENMASK(24, 22)) >> 22) -#defineCOMP1_TX_WORDSIZE_1(r) (((r) & GENMASK(21, 19)) >> 19) -#defineCOMP1_TX_WORDSIZE_0(r) (((r) & GENMASK(18, 16)) >> 16) -#defineCOMP1_TX_CHANNELS(r)(((r) & GENMASK(10, 9)) >> 9) -#defineCOMP1_RX_CHANNELS(r)(((r) & GENMASK(8, 7)) >> 7) -#defineC
[PATCH 0/4 v7] Add I2S audio support for ARC AXS10x boards
ARC AXS10x platforms consist of a mainboard with several peripherals. One of those peripherals is an HDMI output port controlled by the ADV7511 transmitter. This patch set adds I2S audio for the AXS10x platform. NOTE: Although the mainline I2S driver uses ALSA DMA engine, this controller can be built without DMA support so it was necessary to add this custom platform driver so that HDMI audio works in AXS boards. Changes v6 -> v7: * Discard the use of memcpy * Report IRQ_HANDLED only when there is an IRQ * Use interrupts to check if PIO mode is in use * Unmask interrupts only when in PIO mode * Remove empty functions Changes v5 -> v6: * Use SNDRV_DMA_TYPE_CONTINUOUS Changes v4 -> v5: * Resolve undefined references when compiling as module * Dropped adv7511 audio patches * Use DMA properties in I2S to check which mode to use: PIO or DMA (as suggested by Lars-Peter Clausen) Changes v3 -> v4: * Reintroduced custom PCM driver (see note below) * Use DT boolean to switch between ALSA DMA engine PCM or custom PCM * Use fifo depth to program I2S FCR * Update I2S documentation Changes v2 -> v3: * Removed pll_config functions (as suggested by Alexey Brodkin) * Removed HDMI start at adv7511_core (as suggested by Archit Taneja) * Use NOP functions for adv7511_audio (as suggested by Archit Taneja) * Added adv7511_audio_exit() function (as suggested by Archit Taneja) * Moved adv7511 to its own folder (as suggested by Archit Taneja) * Separated file rename of adv7511_core (as suggested by Emil Velikov) * Compile adv7511 as module if ALSA SoC is compiled as module * Load adv7511 audio only if declared in device tree (as suggested by Laurent Pinchart) * Dropped custom platform driver, using now ALSA DMA engine * Dropped IRQ handler for I2S Changes v1 -> v2: * DT bindings moved to separate patch (as suggested by Alexey Brodkin) * Removed defconfigs entries (as suggested by Alexey Brodkin) Cc: Carlos Palminha Cc: Mark Brown Cc: Liam Girdwood Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Rob Herring Cc: Alexey Brodkin Cc: linux-snps-...@lists.infradead.org Cc: alsa-de...@alsa-project.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Jose Abreu (4): ASoC: dwc: Add helper functions to disable/enable irqs ASoC: dwc: Do not use devm_clk_get() if using platform data ASoC: dwc: Add PIO PCM extension ASoC: dwc: Add irq parameter to DOCUMENTATION .../devicetree/bindings/sound/designware-i2s.txt | 4 + sound/soc/dwc/Kconfig | 9 + sound/soc/dwc/Makefile | 5 +- sound/soc/dwc/designware_i2s.c | 229 ++--- sound/soc/dwc/designware_pcm.c | 220 sound/soc/dwc/local.h | 122 +++ 6 files changed, 467 insertions(+), 122 deletions(-) create mode 100644 sound/soc/dwc/designware_pcm.c create mode 100644 sound/soc/dwc/local.h -- 1.9.1
[PATCH 4/4 v7] ASoC: dwc: Add irq parameter to DOCUMENTATION
A parameter description for the interruptions of the I2S controller was added. This interrupt parameter should only be set when I2S does not have DMA support. Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: Mark Brown Cc: Liam Girdwood Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Rob Herring Cc: Alexey Brodkin Cc: linux-snps-...@lists.infradead.org Cc: alsa-de...@alsa-project.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- Changes v6 -> v7: * interrupts is now optional property No changes v5 -> v6. Changes v4 -> v5: * interrupts is now required property * Drop 'snps-use-dmaengine' property This patch was only introduced in v4. Documentation/devicetree/bindings/sound/designware-i2s.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/designware-i2s.txt b/Documentation/devicetree/bindings/sound/designware-i2s.txt index 7bb5424..6a536d5 100644 --- a/Documentation/devicetree/bindings/sound/designware-i2s.txt +++ b/Documentation/devicetree/bindings/sound/designware-i2s.txt @@ -12,6 +12,10 @@ Required properties: one for receive. - dma-names : "tx" for the transmit channel, "rx" for the receive channel. +Optional properties: + - interrupts: The interrupt line number for the I2S controller. Add this + parameter if the I2S controller that you are using does not support DMA. + For more details on the 'dma', 'dma-names', 'clock' and 'clock-names' properties please check: * resource-names.txt -- 1.9.1
[PATCH 1/4 v7] ASoC: dwc: Add helper functions to disable/enable irqs
Helper functions to disable and enable the I2S interrupts were
added. Only the interrupts of the used channels are enabled.
Also, there is no need to enable irqs at dw_i2s_config(), they
are already enabled at startup.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Mark Brown
Cc: Liam Girdwood
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Rob Herring
Cc: Alexey Brodkin
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
This patch was only introduced in v7.
sound/soc/dwc/designware_i2s.c | 68 +-
1 file changed, 41 insertions(+), 27 deletions(-)
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 0db69b7..4c4f0dc 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -145,26 +145,54 @@ static inline void i2s_clear_irqs(struct dw_i2s_dev *dev,
u32 stream)
}
}
-static void i2s_start(struct dw_i2s_dev *dev,
- struct snd_pcm_substream *substream)
+static inline void i2s_disable_irqs(struct dw_i2s_dev *dev, u32 stream,
+ int chan_nr)
{
- struct i2s_clk_config_data *config = &dev->config;
u32 i, irq;
- i2s_write_reg(dev->i2s_base, IER, 1);
- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
- for (i = 0; i < (config->chan_nr / 2); i++) {
+ if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
+ for (i = 0; i < (chan_nr / 2); i++) {
+ irq = i2s_read_reg(dev->i2s_base, IMR(i));
+ i2s_write_reg(dev->i2s_base, IMR(i), irq | 0x30);
+ }
+ } else {
+ for (i = 0; i < (chan_nr / 2); i++) {
+ irq = i2s_read_reg(dev->i2s_base, IMR(i));
+ i2s_write_reg(dev->i2s_base, IMR(i), irq | 0x03);
+ }
+ }
+}
+
+static inline void i2s_enable_irqs(struct dw_i2s_dev *dev, u32 stream,
+ int chan_nr)
+{
+ u32 i, irq;
+
+ if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
+ for (i = 0; i < (chan_nr / 2); i++) {
irq = i2s_read_reg(dev->i2s_base, IMR(i));
i2s_write_reg(dev->i2s_base, IMR(i), irq & ~0x30);
}
- i2s_write_reg(dev->i2s_base, ITER, 1);
} else {
- for (i = 0; i < (config->chan_nr / 2); i++) {
+ for (i = 0; i < (chan_nr / 2); i++) {
irq = i2s_read_reg(dev->i2s_base, IMR(i));
i2s_write_reg(dev->i2s_base, IMR(i), irq & ~0x03);
}
- i2s_write_reg(dev->i2s_base, IRER, 1);
}
+}
+
+static void i2s_start(struct dw_i2s_dev *dev,
+ struct snd_pcm_substream *substream)
+{
+ struct i2s_clk_config_data *config = &dev->config;
+
+ i2s_write_reg(dev->i2s_base, IER, 1);
+ i2s_enable_irqs(dev, substream->stream, config->chan_nr);
+
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+ i2s_write_reg(dev->i2s_base, ITER, 1);
+ else
+ i2s_write_reg(dev->i2s_base, IRER, 1);
i2s_write_reg(dev->i2s_base, CER, 1);
}
@@ -172,24 +200,14 @@ static void i2s_start(struct dw_i2s_dev *dev,
static void i2s_stop(struct dw_i2s_dev *dev,
struct snd_pcm_substream *substream)
{
- u32 i = 0, irq;
i2s_clear_irqs(dev, substream->stream);
- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
i2s_write_reg(dev->i2s_base, ITER, 0);
-
- for (i = 0; i < 4; i++) {
- irq = i2s_read_reg(dev->i2s_base, IMR(i));
- i2s_write_reg(dev->i2s_base, IMR(i), irq | 0x30);
- }
- } else {
+ else
i2s_write_reg(dev->i2s_base, IRER, 0);
- for (i = 0; i < 4; i++) {
- irq = i2s_read_reg(dev->i2s_base, IMR(i));
- i2s_write_reg(dev->i2s_base, IMR(i), irq | 0x03);
- }
- }
+ i2s_disable_irqs(dev, substream->stream, 8);
if (!dev->active) {
i2s_write_reg(dev->i2s_base, CER, 0);
@@ -223,7 +241,7 @@ static int dw_i2s_startup(struct snd_pcm_substream
*substream,
static void dw_i2s_config(struct dw_i2s_dev *dev, int stream)
{
- u32 ch_reg, irq;
+ u32 ch_reg;
struct i2s_clk_config_data *config = &dev->config;
@@ -235,16 +253,12 @@ static void dw_i2s_config(struct dw_i2s_dev *dev, int
stream)
dev->xfer_resolution);
i2s_write_reg
[PATCH 2/4 v7] ASoC: dwc: Do not use devm_clk_get() if using platform data
When using platform data the devm_clk_get() function is
called causing a probe failure if the clock is not
declared. As we can pass the clock handler by platform
data call only devm_clk_get() when platform data is not
used.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Mark Brown
Cc: Liam Girdwood
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Rob Herring
Cc: Alexey Brodkin
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
This patch was only introduced in v7.
sound/soc/dwc/designware_i2s.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 4c4f0dc..a97be8e 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -690,15 +690,16 @@ static int dw_i2s_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "no clock configure
method\n");
return -ENODEV;
}
- }
- dev->clk = devm_clk_get(&pdev->dev, clk_id);
+ } else {
+ dev->clk = devm_clk_get(&pdev->dev, clk_id);
- if (IS_ERR(dev->clk))
- return PTR_ERR(dev->clk);
+ if (IS_ERR(dev->clk))
+ return PTR_ERR(dev->clk);
- ret = clk_prepare_enable(dev->clk);
- if (ret < 0)
- return ret;
+ ret = clk_prepare_enable(dev->clk);
+ if (ret < 0)
+ return ret;
+ }
}
dev_set_drvdata(&pdev->dev, dev);
--
1.9.1
Re: [PATCH 3/4 v7] ASoC: dwc: Add PIO PCM extension
Hi Mark,
Thanks for your comments.
On 24-05-2016 17:41, Mark Brown wrote:
> On Mon, May 23, 2016 at 11:02:24AM +0100, Jose Abreu wrote:
>
>> +config SND_DESIGNWARE_PCM
>> +bool "PCM PIO extension for I2S driver"
> Why can't this be built as a module?
I can change but my intention was to make this PCM a kind of extension to the
driver instead of adding a new module to the system.
>
>> +
>> +return irq_valid ? IRQ_HANDLED : IRQ_NONE;
> Please write a normal if statement, the ternery operator doesn't help
> legibility.
Ok.
>
>> static void i2s_start(struct dw_i2s_dev *dev,
>>struct snd_pcm_substream *substream)
>> {
>> struct i2s_clk_config_data *config = &dev->config;
>>
>> i2s_write_reg(dev->i2s_base, IER, 1);
>> -i2s_enable_irqs(dev, substream->stream, config->chan_nr);
>> +
>> +if (dev->use_pio)
>> +i2s_enable_irqs(dev, substream->stream, config->chan_nr);
>>
>> if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
>> i2s_write_reg(dev->i2s_base, ITER, 1);
> That seems wrong, or at least something that should be separate?
> Previously we needed interrupts for DMA operation but now we enable
> interrupts only if we don't use DMA. It feels like we want to make the
> change for DMA separately if only to make it clear for bisection, are we
> 100% sure that masking the interrupt won't also mask the DMA request
> signals?
Indeed I thought about this and the interrupts must also be enabled when in DMA
mode. Although there is no interrupt handler in the original driver (without
this patches) in some setups the interrupt line may be connected to the DMA
controller. I will drop this change and always enable interrupts. Please note
that I don't have a setup with DMA support so I can only test using the PIO
mode.
>> +irq = platform_get_irq(pdev, 0);
>> +if (irq >= 0) {
>> +dev_dbg(&pdev->dev, "using PIO mode\n");
>> +dev->use_pio = true;
>> +
>> +ret = devm_request_irq(&pdev->dev, irq, i2s_irq_handler, 0,
>> +pdev->name, dev);
>> +if (ret < 0) {
>> +dev_err(&pdev->dev, "failed to request irq\n");
>> +return ret;
>> +}
>> +}
> This also seems wrong. We're forcing PIO if an interrupt is provided
> rather than based on DMA being configured which means that if the
> interrupt is wired up and happens to be described in DT we'll get worse
> performance. People should be able to just describe the system without
> worrying about this, and we might find some other use for the interrupts
> in future. Indeed right now it would probably be reasonable to use the
> error interrupts all the time if they're available.
How should I then determine which mode to use?
- Check if DMA parameters are declared in DT, or
- Check if snd_dmaengine_pcm_register() fails, or
- Assume PIO mode will be used when compiling with PIO PCM, or
- Something else ?
Best regards,
Jose Miguel Abreu
Re: [PATCH 3/4 v7] ASoC: dwc: Add PIO PCM extension
Hi Mark, On 24-05-2016 18:51, Mark Brown wrote: > On Tue, May 24, 2016 at 06:07:14PM +0100, Jose Abreu wrote: >> On 24-05-2016 17:41, Mark Brown wrote: > Please fix your mail client to word wrap within paragraphs at something > substantially less than 80 columns. Doing this makes your messages much > easier to read and reply to. > >>>>if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) >>>>i2s_write_reg(dev->i2s_base, ITER, 1); >>> That seems wrong, or at least something that should be separate? >>> Previously we needed interrupts for DMA operation but now we enable >>> interrupts only if we don't use DMA. It feels like we want to make the >>> change for DMA separately if only to make it clear for bisection, are we >>> 100% sure that masking the interrupt won't also mask the DMA request >>> signals? >> Indeed I thought about this and the interrupts must also be enabled when in >> DMA >> mode. Although there is no interrupt handler in the original driver (without >> this patches) in some setups the interrupt line may be connected to the DMA >> controller. I will drop this change and always enable interrupts. Please note >> that I don't have a setup with DMA support so I can only test using the PIO >> mode. > Presumably you can talk to your hardware colleagues and get them to make > you a FPGA with a DMA IP available? Its already in the todo list. > >>> This also seems wrong. We're forcing PIO if an interrupt is provided >>> rather than based on DMA being configured which means that if the >>> interrupt is wired up and happens to be described in DT we'll get worse >> How should I then determine which mode to use? >> - Check if DMA parameters are declared in DT, or >> - Check if snd_dmaengine_pcm_register() fails, or >> - Assume PIO mode will be used when compiling with PIO PCM, or >> - Something else ? > You could either unconditionally register the PIO driver and only > actually start using it if the driver is instantiated or you could check > to see if the registration function works (handling deferred probe - if > the DMA driver just didn't load yet you should wait for it). I think I will take the second option. Something like this: " ret = snd_dmaengine_pcm_register(...) if (ret == -EPROBE_DEFER) return ret; else pio_register(...); "? Best regards, Jose Miguel Abreu
Re: [PATCH 3/4 v7] ASoC: dwc: Add PIO PCM extension
Hi Mark,
On 25-05-2016 11:18, Mark Brown wrote:
> On Wed, May 25, 2016 at 11:11:47AM +0100, Jose Abreu wrote:
>
>> I think I will take the second option. Something like this:
>> "
>> ret = snd_dmaengine_pcm_register(...)
>> if (ret == -EPROBE_DEFER)
>> return ret;
>> else
>> pio_register(...);
>> "?
> Sure. You should print a diagnostic if you fail to get the DMA, for any
> real system it's going to be a bug.
Ok, will do that. I noticed the last I2S patch that you merged
("ASoC: dwc: Add helper functions to disable/enable irqs") is not
in for-next yet. Should I base my work on 'topic/dwc' branch?
Best regards,
Jose Miguel Abreu
DRM DMA Engine
Hi all, Currently I am trying to develop a DRM driver that will use Xilinx VDMA to transfer video data to a HDMI TX Phy and I am facing a difficulty regarding the understanding of the DRM DMA Engine. I looked at several sources and at the DRM core source but the flow of creating and interfacing with the DMA controller is still not clear to me. At DRI web page the X server is mentioned. Does it mean that the channel creation and handling is done by the X server? If so, what is the DRM driver responsible to do then and what exactly does the DRM core do? As I am using Xilinx VDMA do you foresee any special implementation details? Just for reference here is the description of the Xilinx VDMA: "The Advanced eXtensible Interface Video Direct Memory Access (AXI VDMA) core is a soft Xilinx Intellectual Property (IP) core providing high-bandwidth direct memory access between memory and AXI4-Stream video type target peripherals including peripherals which support AXI4-Stream Video Protocol." The driver is available at "drivers/dma/xilinx/xilinx_vdma.c". Another important point: I am using PCI Express connected to a FPGA which has all the necessary components (Xilinx VDMA, I2S, ...) and the HDMI TX Phy. Looking forward to you help. Best regards, Jose Miguel Abreu
[PATCH 2/2 v6] ASoC: dwc: Update DOCUMENTATION for I2S Driver
This patch updates documentation for the Designware I2S
driver.
Signed-off-by: Jose Abreu
Acked-by: Rob Herring
Cc: Rob Herring
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: devicet...@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
No changes v5 -> v6.
Changes v4 -> v5:
* interrupts is now required property
* Drop 'snps-use-dmaengine' property
This patch was only introduced in v4.
Documentation/devicetree/bindings/sound/designware-i2s.txt | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/designware-i2s.txt
b/Documentation/devicetree/bindings/sound/designware-i2s.txt
index 7bb5424..27a728f 100644
--- a/Documentation/devicetree/bindings/sound/designware-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/designware-i2s.txt
@@ -3,14 +3,18 @@ DesignWare I2S controller
Required properties:
- compatible : Must be "snps,designware-i2s"
- reg : Must contain the I2S core's registers location and length
+ - interrupts: where IRQ is the interrupt number.
- clocks : Pairs of phandle and specifier referencing the controller's
clocks. The controller expects one clock: the clock used as the sampling
rate reference clock sample.
- clock-names : "i2sclk" for the sample rate reference clock.
+
+Optional properties:
- dmas: Pairs of phandle and specifier for the DMA channels that are used by
the core. The core expects one or two dma channels: one for transmit and
- one for receive.
- - dma-names : "tx" for the transmit channel, "rx" for the receive channel.
+ one for receive. Set this parameter if the I2S DMA block is enabled.
+ - dma-names : "tx" for the transmit channel, "rx" for the receive channel. Set
+ this parameter if the I2S DMA block is enabled.
For more details on the 'dma', 'dma-names', 'clock' and 'clock-names'
properties please check:
@@ -23,6 +27,7 @@ Example:
soc_i2s: i2s@7ff9 {
compatible = "snps,designware-i2s";
reg = <0x0 0x7ff9 0x0 0x1000>;
+ interrupts = <15>;
clocks = <&scpi_i2sclk 0>;
clock-names = "i2sclk";
#sound-dai-cells = <0>;
--
1.9.1
[PATCH 1/2 v6] ASoC: dwc: Add custom PCM driver
HDMI audio support was added to the AXS board using an
I2S cpu driver and a custom platform driver.
The platform driver supports two channels @ 16 bits with
rates 32k, 44.1k and 48k.
Although the mainline I2S driver uses ALSA DMA engine,
this controller can be built without DMA support so it
was necessary to add this custom platform driver so that
HDMI audio works in AXS boards.
The selection between the use of DMA engine or PIO mode
is detected by declaring or not the DMA parameters in
the device tree.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Mark Brown
Cc: Liam Girdwood
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Alexey Brodkin
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
Changes v5 -> v6:
* Use SNDRV_DMA_TYPE_CONTINUOUS
Changes v4 -> v5:
* Resolve undefined references when compiling as module
* Use DMA properties in I2S to check which mode to use: PIO or DMA (as
suggested by Lars-Peter Clausen)
Changes v3 -> v4:
* Reintroduced custom PCM driver
* Use DT boolean to switch between ALSA DMA engine PCM or custom PCM
Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S
No changes v1 -> v2.
sound/soc/dwc/Kconfig | 9 ++
sound/soc/dwc/Makefile | 1 +
sound/soc/dwc/designware.h | 71 +
sound/soc/dwc/designware_i2s.c | 94 -
sound/soc/dwc/designware_pcm.c | 228 +
5 files changed, 376 insertions(+), 27 deletions(-)
create mode 100644 sound/soc/dwc/designware.h
create mode 100644 sound/soc/dwc/designware_pcm.c
diff --git a/sound/soc/dwc/Kconfig b/sound/soc/dwc/Kconfig
index d50e085..2a21120 100644
--- a/sound/soc/dwc/Kconfig
+++ b/sound/soc/dwc/Kconfig
@@ -7,4 +7,13 @@ config SND_DESIGNWARE_I2S
Synopsys desigwnware I2S device. The device supports upto
maximum of 8 channels each for play and record.
+config SND_DESIGNWARE_PCM
+ tristate "Synopsys I2S PCM Driver"
+ help
+Say Y or M if you want to add support for ALSA ASoC platform driver
+using I2S.
+
+Select this option if you want to be able to create a sound interface
+using the I2S device driver as CPU driver. Instead of using ALSA
+DMA engine by selecting this driver a custom PCM driver will be used.
diff --git a/sound/soc/dwc/Makefile b/sound/soc/dwc/Makefile
index 319371f..1b48bccc 100644
--- a/sound/soc/dwc/Makefile
+++ b/sound/soc/dwc/Makefile
@@ -1,3 +1,4 @@
# SYNOPSYS Platform Support
obj-$(CONFIG_SND_DESIGNWARE_I2S) += designware_i2s.o
+obj-$(CONFIG_SND_DESIGNWARE_PCM) += designware_pcm.o
diff --git a/sound/soc/dwc/designware.h b/sound/soc/dwc/designware.h
new file mode 100644
index 000..09fafee
--- /dev/null
+++ b/sound/soc/dwc/designware.h
@@ -0,0 +1,71 @@
+/*
+ * ALSA SoC Synopsys Audio Layer
+ *
+ * sound/soc/dwc/designware.h
+ *
+ * Copyright (C) 2016 Synopsys
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __DESIGNWARE_H
+#define __DESIGNWARE_H
+
+#include
+#include
+#include
+#include
+#include
+
+struct dw_pcm_binfo {
+ struct snd_pcm_substream *stream;
+ unsigned char *dma_base;
+ unsigned char *dma_pointer;
+ unsigned int period_size_frames;
+ unsigned int size;
+ snd_pcm_uframes_t period_pointer;
+ unsigned int total_periods;
+ unsigned int current_period;
+};
+
+union dw_i2s_snd_dma_data {
+ struct i2s_dma_data pd;
+ struct snd_dmaengine_dai_dma_data dt;
+};
+
+struct dw_i2s_dev {
+ void __iomem *i2s_base;
+ struct clk *clk;
+ int active;
+ unsigned int capability;
+ unsigned int quirks;
+ unsigned int i2s_reg_comp1;
+ unsigned int i2s_reg_comp2;
+ struct device *dev;
+ u32 ccr;
+ u32 xfer_resolution;
+ u32 fifo_th;
+
+ /* data related to DMA transfers b/w i2s and DMAC */
+ bool use_dmaengine;
+ union dw_i2s_snd_dma_data play_dma_data;
+ union dw_i2s_snd_dma_data capture_dma_data;
+ struct i2s_clk_config_data config;
+ int (*i2s_clk_cfg)(struct i2s_clk_config_data *config);
+ struct dw_pcm_binfo binfo;
+};
+
+#if IS_ENABLED(CONFIG_SND_DESIGNWARE_PCM)
+int dw_pcm_transfer(u32 *lsample, u32 *rsample, int bytes, int buf_size,
+ struct dw_pcm_binfo *bi);
+#else
+int dw_pcm_transfer(u32 *lsample, u32 *rsample, int bytes, int buf_size,
+ struct dw_pcm_binfo *bi)
+{
+ return 0;
+}
+#endif
+
+#endif
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 0db69b7..5ee0faf 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designwar
[PATCH 0/2 v6] Add I2S audio support for ARC AXS10x boards
ARC AXS10x platforms consist of a mainboard with several peripherals. One of those peripherals is an HDMI output port controlled by the ADV7511 transmitter. This patch set adds I2S audio for the AXS10x platform. Changes v5 -> v6 * Use SNDRV_DMA_TYPE_CONTINUOUS Changes v4 -> v5 * Resolve undefined references when compiling as module * Dropped adv7511 audio patches * Use DMA properties in I2S to check which mode to use: PIO or DMA (as suggested by Lars-Peter Clausen) Changes v3 -> v4: * Reintroduced custom PCM driver (see note below) * Use DT boolean to switch between ALSA DMA engine PCM or custom PCM * Use fifo depth to program I2S FCR * Update I2S documentation Changes v2 -> v3: * Removed pll_config functions (as suggested by Alexey Brodkin) * Removed HDMI start at adv7511_core (as suggested by Archit Taneja) * Use NOP functions for adv7511_audio (as suggested by Archit Taneja) * Added adv7511_audio_exit() function (as suggested by Archit Taneja) * Moved adv7511 to its own folder (as suggested by Archit Taneja) * Separated file rename of adv7511_core (as suggested by Emil Velikov) * Compile adv7511 as module if ALSA SoC is compiled as module * Load adv7511 audio only if declared in device tree (as suggested by Laurent Pinchart) * Dropped custom platform driver, using now ALSA DMA engine * Dropped IRQ handler for I2S Changes v1 -> v2: * DT bindings moved to separate patch (as suggested by Alexey Brodkin) * Removed defconfigs entries (as suggested by Alexey Brodkin) NOTE: Although the mainline I2S driver uses ALSA DMA engine, this controller can be built without DMA support so it was necessary to add this custom platform driver so that HDMI audio works in AXS boards. Cc: Carlos Palminha Cc: Mark Brown Cc: Liam Girdwood Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Rob Herring Cc: Alexey Brodkin Cc: linux-snps-...@lists.infradead.org Cc: alsa-de...@alsa-project.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Jose Abreu (2): ASoC: dwc: Add custom PCM driver ASoC: dwc: Update DOCUMENTATION for I2S Driver .../devicetree/bindings/sound/designware-i2s.txt | 9 +- sound/soc/dwc/Kconfig | 9 + sound/soc/dwc/Makefile | 1 + sound/soc/dwc/designware.h | 71 +++ sound/soc/dwc/designware_i2s.c | 94 ++--- sound/soc/dwc/designware_pcm.c | 228 + 6 files changed, 383 insertions(+), 29 deletions(-) create mode 100644 sound/soc/dwc/designware.h create mode 100644 sound/soc/dwc/designware_pcm.c -- 1.9.1
Re: [PATCH 2/2 v6] ASoC: dwc: Update DOCUMENTATION for I2S Driver
Hi Mark,
Sorry. Follows bellow.
On 27-04-2016 11:05, Jose Abreu wrote:
> This patch updates documentation for the Designware I2S
> driver.
>
> Signed-off-by: Jose Abreu
> Acked-by: Rob Herring
> Cc: Rob Herring
> Cc: Carlos Palminha
> Cc: Alexey Brodkin
> Cc: devicet...@vger.kernel.org
> Cc: linux-snps-...@lists.infradead.org
> Cc: alsa-de...@alsa-project.org
> Cc: linux-kernel@vger.kernel.org
> ---
>
> No changes v5 -> v6.
>
> Changes v4 -> v5:
> * interrupts is now required property
> * Drop 'snps-use-dmaengine' property
>
> This patch was only introduced in v4.
>
> Documentation/devicetree/bindings/sound/designware-i2s.txt | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/designware-i2s.txt
> b/Documentation/devicetree/bindings/sound/designware-i2s.txt
> index 7bb5424..27a728f 100644
> --- a/Documentation/devicetree/bindings/sound/designware-i2s.txt
> +++ b/Documentation/devicetree/bindings/sound/designware-i2s.txt
> @@ -3,14 +3,18 @@ DesignWare I2S controller
> Required properties:
> - compatible : Must be "snps,designware-i2s"
> - reg : Must contain the I2S core's registers location and length
> + - interrupts: where IRQ is the interrupt number.
> - clocks : Pairs of phandle and specifier referencing the controller's
> clocks. The controller expects one clock: the clock used as the sampling
> rate reference clock sample.
> - clock-names : "i2sclk" for the sample rate reference clock.
> +
> +Optional properties:
> - dmas: Pairs of phandle and specifier for the DMA channels that are used by
> the core. The core expects one or two dma channels: one for transmit and
> - one for receive.
> - - dma-names : "tx" for the transmit channel, "rx" for the receive channel.
> + one for receive. Set this parameter if the I2S DMA block is enabled.
> + - dma-names : "tx" for the transmit channel, "rx" for the receive channel.
> Set
> + this parameter if the I2S DMA block is enabled.
>
> For more details on the 'dma', 'dma-names', 'clock' and 'clock-names'
> properties please check:
> @@ -23,6 +27,7 @@ Example:
> soc_i2s: i2s@7ff9 {
> compatible = "snps,designware-i2s";
> reg = <0x0 0x7ff9 0x0 0x1000>;
> + interrupts = <15>;
> clocks = <&scpi_i2sclk 0>;
> clock-names = "i2sclk";
> #sound-dai-cells = <0>;
Re: [RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver
Hi Stephen,
On 20-04-2016 02:54, Stephen Boyd wrote:
> On 04/19, Jose Abreu wrote:
>> @Stephen: can you give some input so that I can submit a v6?
>>
> I don't prefer putting the second register in the same DT node,
> but that's really up to the DT reviewers to approve such a
> design. The current binding has been acked by Rob right?
Yes.
> Assuming the new binding is acked/reviewed then that solution is
> fine.
Ok, will then use the DT to pass the FPGA version register.
> Otherwise, I still prefer two DTS files for the two different FPGA
> versions. At the least, please use ioremap for any pointers that
> you readl/writel here.
>
> Beyond that, we should have a fixed rate source clk somewhere in
> the software view of the clk tree, because that reflects reality.
> Hardcoding the parent rate in the structure works, but doesn't
> properly express the clk tree.
>
Can I use a property in the DT to pass this reference clock? something like
this:
snps,parent-freq = <0xFBED9 2700>, <0x0 28224000>; /* Tuple
, fpga-version = 0 is default */
Or use a parent clock? like:
clk {
compatible = "fixed-clock";
clock-frequency = <2700>;
#clock-cells = <0>;
snps,fpga-version = <0xFBED9>;
}
It is important to distinguish between the different versions automatically, is
any of these solutions ok?
Best regards,
Jose Miguel Abreu
Re: [RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver
Hi Alexey,
On 20-04-2016 17:12, Alexey Brodkin wrote:
> Hi Jose, Stephen,
>
> On Wed, 2016-04-20 at 10:47 +0100, Jose Abreu wrote:
>> Hi Stephen,
>>
>>
>> On 20-04-2016 02:54, Stephen Boyd wrote:
>>> On 04/19, Jose Abreu wrote:
>>>> @Stephen: can you give some input so that I can submit a v6?
>>>>
>>> I don't prefer putting the second register in the same DT node,
>>> but that's really up to the DT reviewers to approve such a
>>> design. The current binding has been acked by Rob right?
>> Yes.
>>
>>> Assuming the new binding is acked/reviewed then that solution is
>>> fine.
>> Ok, will then use the DT to pass the FPGA version register.
> We won't need to know FPGA version at all I think.
> Read my comment below.
>
>>> Otherwise, I still prefer two DTS files for the two different FPGA
>>> versions. At the least, please use ioremap for any pointers that
>>> you readl/writel here.
>>>
>>> Beyond that, we should have a fixed rate source clk somewhere in
>>> the software view of the clk tree, because that reflects reality.
>>> Hardcoding the parent rate in the structure works, but doesn't
>>> properly express the clk tree.
>>>
>> Can I use a property in the DT to pass this reference clock? something like
>> this:
>> snps,parent-freq = <0xFBED9 2700>, <0x0 28224000>; /* Tuple
>> , fpga-version = 0 is default */
>>
>> Or use a parent clock? like:
>> clk {
>> compatible = "fixed-clock";
>> clock-frequency = <2700>;
>> #clock-cells = <0>;
>> snps,fpga-version = <0xFBED9>;
>> }
>>
>> It is important to distinguish between the different versions automatically,
>> is
>> any of these solutions ok?
> I do like that solution with a master clock but with some fine-tuning
> for simplification.
>
> We'll add master clock node for I2S as a fixed clock like that:
> --->8--
> i2s_master_clock: clk {
> #clock-cells = <0>;
> compatible = "fixed-clock";
> clock-frequency = <2700>;
> };
> --->8--
>
> Note there's no mention of MB version, just a value of the frequency.
> And in the driver itself value of that master clock will be used for
> population of "pll_clk->ref_clk" directly.
>
> These are benefits we'll get with that approach:
> [1] We escape any IOs not related to our clock device (I mean
> "snps,i2s-pll-clock") itself.
> [2] We'll use whatever reference clock value is given.
> I.e. we'll be able to do a fix-up of that reference clock
> value early in platform code depending on HW we're running on.
> That's what people do here and there.
> [3] Remember another clock driver for AXS10x board is right around
> the corner. I mean the one for ARC PGU which uses exactly the same
> master clock. So one fixup as mentioned above will work
> at once for 2 clock drivers.
>
> Let me know if above makes sense.
That approach can't be used because the reference clock value will change in the
next firmware release. The new release will have a reference clock of 28224000
Hz instead of the usual 2700 Hz, so we need to have a way to distinguish
between them. Because of that we can't have only one master clock unless you
state to users that they have to change the reference clock value when using the
new firmware release. Stephen suggested to use two DT files (one for each
firmware release), but as Vineet said this would be annoying to the user so I am
trying to use another solution so that only one DT file is required.
>
> -Alexey
Best regards,
Jose Miguel Abreu
Re: [RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver
Hi Alexey,
On 21-04-2016 13:18, Alexey Brodkin wrote:
> Hi Jose,
>
> On Thu, 2016-04-21 at 10:51 +0100, Jose Abreu wrote:
>> Hi Alexey,
>
>>>>> Otherwise, I still prefer two DTS files for the two different FPGA
>>>>> versions. At the least, please use ioremap for any pointers that
>>>>> you readl/writel here.
>>>>>
>>>>> Beyond that, we should have a fixed rate source clk somewhere in
>>>>> the software view of the clk tree, because that reflects reality.
>>>>> Hardcoding the parent rate in the structure works, but doesn't
>>>>> properly express the clk tree.
>>>>>
>>>> Can I use a property in the DT to pass this reference clock? something
>>>> like this:
>>>> snps,parent-freq = <0xFBED9 2700>, <0x0 28224000>; /* Tuple
>>>> , fpga-version = 0 is default */
>>>>
>>>> Or use a parent clock? like:
>>>> clk {
>>>> compatible = "fixed-clock";
>>>> clock-frequency = <2700>;
>>>> #clock-cells = <0>;
>>>> snps,fpga-version = <0xFBED9>;
>>>> }
>>>>
>>>> It is important to distinguish between the different versions
>>>> automatically, is
>>>> any of these solutions ok?
>>> I do like that solution with a master clock but with some fine-tuning
>>> for simplification.
>>>
>>> We'll add master clock node for I2S as a fixed clock like that:
>>> --->8--
>>> i2s_master_clock: clk {
>>> #clock-cells = <0>;
>>> compatible = "fixed-clock";
>>> clock-frequency = <2700>;
>>> };
>>> --->8--
>>>
>>> Note there's no mention of MB version, just a value of the frequency.
>>> And in the driver itself value of that master clock will be used for
>>> population of "pll_clk->ref_clk" directly.
>>>
>>> These are benefits we'll get with that approach:
>>> [1] We escape any IOs not related to our clock device (I mean
>>> "snps,i2s-pll-clock") itself.
>>> [2] We'll use whatever reference clock value is given.
>>> I.e. we'll be able to do a fix-up of that reference clock
>>> value early in platform code depending on HW we're running on.
>>> That's what people do here and there.
>>> [3] Remember another clock driver for AXS10x board is right around
>>> the corner. I mean the one for ARC PGU which uses exactly the same
>>> master clock. So one fixup as mentioned above will work
>>> at once for 2 clock drivers.
>>>
>>> Let me know if above makes sense.
>> That approach can't be used because the reference clock value will change in
>> the
>> next firmware release. The new release will have a reference clock of
>> 28224000
>> Hz instead of the usual 2700 Hz, so we need to have a way to distinguish
>> between them. Because of that we can't have only one master clock unless you
>> state to users that they have to change the reference clock value when using
>> the
>> new firmware release. Stephen suggested to use two DT files (one for each
>> firmware release), but as Vineet said this would be annoying to the user so
>> I am
>> trying to use another solution so that only one DT file is required.
> Ok reference clock will change.
> But I may guess we'll still be able to determine at least that new
> firmware version in run-time, right? If so we'll update a fix-up in
> early axs10x platform code so that reference clock will be set as 28224000 Hz.
Yes, there is a register where the FPGA version date is encoded, we can use that
to check which firmware is used (if date <= old_firmware_date then
clock=2700; else clock=28224000). If that fix is acceptable it could be a
good solution without having to use custom parameters in the DT (no need to
encode the different clocks and we would only use one master clock) but I am not
sure where and how this can be encoded and I don't know how to change the DT on
runtime. Can you give me some guidelines?
>
> And indeed 2 DT files is a no go - we want to run the same one binary
> (with built-in .dtb) on all flavors of AXS boards. And fix-up I'm talking
> about
> will actually do transformation of .dtb early on kernel boot process so that
> will
> be a complete equivalent of different DT files.
And doing modifications on the DT can cause some misdirections to users.
Besides, we would have clock specific functions in init procedures which is
precisely what we are trying to avoid by submitting this driver.
>
> -Alexey
Best regards,
Jose Miguel Abreu
[PATCH 0/2 v6] Add AXS10X I2S PLL clock driver
The ARC SDP I2S clock can be programmed using a
specific PLL.
This patch series has the goal of adding a clock driver
that programs this PLL.
Changes v5 -> v6:
* Use parent clock to determine PLL input rate instead of using hardcoded values
* Documentation update (added 'clocks' field)
* Device tree update (added 'clocks' field)
Changes v4 -> v5:
* Documentation update (as suggested by Alexey Brodkin)
* Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by
Alexey Brodkin)
* Added DT bindings
Changes v3 -> v4:
* Added binding document (as suggested by Stephen Boyd)
* Minor code style fixes (as suggested by Stephen Boyd)
* Use ioremap (as suggested by Stephen Boyd)
* Implement round_rate (as suggested by Stephen Boyd)
* Change to platform driver (as suggested by Stephen Boyd)
* Use {readl/writel}_relaxed (as suggested by Vineet Gupta)
Changes v2 -> v3:
* Implemented recalc_rate
Changes v1 -> v2:
* Renamed folder to axs10x (as suggested by Alexey Brodkin)
* Added more supported rates
Jose Abreu (2):
clk/axs10x: Add I2S PLL clock driver
arc: axs10x: Add DT bindings for I2S PLL Clock
.../bindings/clock/axs10x-i2s-pll-clock.txt| 25 +++
arch/arc/boot/dts/axs10x_mb.dtsi | 13 ++
drivers/clk/Makefile | 1 +
drivers/clk/axs10x/Makefile| 1 +
drivers/clk/axs10x/i2s_pll_clock.c | 228 +
5 files changed, 268 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
create mode 100644 drivers/clk/axs10x/Makefile
create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c
--
1.9.1
[PATCH 1/2 v6] clk/axs10x: Add I2S PLL clock driver
The ARC SDP I2S clock can be programmed using a
specific PLL.
This patch has the goal of adding a clock driver
that programs this PLL.
At this moment the rate values are hardcoded in
a table but in the future it would be ideal to
use a function which determines the PLL values
given the desired rate.
Signed-off-by: Jose Abreu
---
Changes v5 -> v6:
* Use parent clock to determine PLL input rate instead of using hardcoded values
* Documentation update (added 'clocks' field)
Changes v4 -> v5:
* Documentation update (as suggested by Alexey Brodkin)
* Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by
Alexey Brodkin)
Changes v3 -> v4:
* Added binding document (as suggested by Stephen Boyd)
* Minor code style fixes (as suggested by Stephen Boyd)
* Use ioremap (as suggested by Stephen Boyd)
* Implement round_rate (as suggested by Stephen Boyd)
* Change to platform driver (as suggested by Stephen Boyd)
* Use {readl/writel}_relaxed (as suggested by Vineet Gupta)
Changes v2 -> v3:
* Implemented recalc_rate
Changes v1 -> v2:
* Renamed folder to axs10x (as suggested by Alexey Brodkin)
* Added more supported rates
.../bindings/clock/axs10x-i2s-pll-clock.txt| 25 +++
drivers/clk/Makefile | 1 +
drivers/clk/axs10x/Makefile| 1 +
drivers/clk/axs10x/i2s_pll_clock.c | 228 +
4 files changed, 255 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
create mode 100644 drivers/clk/axs10x/Makefile
create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c
diff --git a/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
new file mode 100644
index 000..5ffc8df
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
@@ -0,0 +1,25 @@
+Binding for the AXS10X I2S PLL clock
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible: shall be "snps,axs10x-i2s-pll-clock"
+- reg : address and length of the I2S PLL register set.
+- clocks: shall be the input parent clock phandle for the PLL.
+- #clock-cells: from common clock binding; Should always be set to 0.
+
+Example:
+ pll_clock: pll_clock {
+ compatible = "fixed-clock";
+ clock-frequency = <2700>;
+ #clock-cells = <0>;
+ };
+
+ i2s_clock@100a0 {
+ compatible = "snps,axs10x-i2s-pll-clock";
+ reg = <0x100a0 0x10>;
+ clocks = <&pll_clock>;
+ #clock-cells = <0>;
+ };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 46869d6..2ca62dc6 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -84,3 +84,4 @@ obj-$(CONFIG_X86) += x86/
obj-$(CONFIG_ARCH_ZX) += zte/
obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
obj-$(CONFIG_H8300)+= h8300/
+obj-$(CONFIG_ARC_PLAT_AXS10X) += axs10x/
diff --git a/drivers/clk/axs10x/Makefile b/drivers/clk/axs10x/Makefile
new file mode 100644
index 000..01996b8
--- /dev/null
+++ b/drivers/clk/axs10x/Makefile
@@ -0,0 +1 @@
+obj-y += i2s_pll_clock.o
diff --git a/drivers/clk/axs10x/i2s_pll_clock.c
b/drivers/clk/axs10x/i2s_pll_clock.c
new file mode 100644
index 000..411310d
--- /dev/null
+++ b/drivers/clk/axs10x/i2s_pll_clock.c
@@ -0,0 +1,228 @@
+/*
+ * Synopsys AXS10X SDP I2S PLL clock driver
+ *
+ * Copyright (C) 2016 Synopsys
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* PLL registers addresses */
+#define PLL_IDIV_REG 0x0
+#define PLL_FBDIV_REG 0x4
+#define PLL_ODIV0_REG 0x8
+#define PLL_ODIV1_REG 0xC
+
+struct i2s_pll_cfg {
+ unsigned int rate;
+ unsigned int idiv;
+ unsigned int fbdiv;
+ unsigned int odiv0;
+ unsigned int odiv1;
+};
+
+static const struct i2s_pll_cfg i2s_pll_cfg_27m[] = {
+ /* 27 Mhz */
+ { 1024000, 0x104, 0x451, 0x10E38, 0x2000 },
+ { 1411200, 0x104, 0x596, 0x10D35, 0x2000 },
+ { 1536000, 0x208, 0xA28, 0x10B2C, 0x2000 },
+ { 2048000, 0x82, 0x451, 0x10E38, 0x2000 },
+ { 2822400, 0x82, 0x596, 0x10D35, 0x2000 },
+ { 3072000, 0x104, 0xA28, 0x10B2C, 0x2000 },
+ { 2116800, 0x82, 0x3CF, 0x10C30, 0x2000 },
+ { 2304000, 0x104, 0x79E, 0x10B2C, 0x2000 },
+ { 0, 0, 0, 0, 0 },
+};
+
+static const struct i2s_pll_cfg i2s_pll_cfg_28m[] = {
+ /* 28.224 Mhz */
+ { 1024000, 0x82, 0x105, 0x107DF,
[PATCH 2/2 v6] arc: axs10x: Add DT bindings for I2S PLL Clock
Add device tree bindings for AXS10X I2S PLL Clock driver.
Signed-off-by: Jose Abreu
---
Changes v5 -> v6:
* Added 'clocks' field
This patch was only introduced in v5.
arch/arc/boot/dts/axs10x_mb.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index ab5d570..5c6489e 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -16,7 +16,20 @@
ranges = <0x 0xe000 0x1000>;
interrupt-parent = <&mb_intc>;
+ i2sclk: i2sclk@100a0 {
+ compatible = "snps,axs10x-i2s-pll-clock";
+ reg = <0x100a0 0x10>;
+ clocks = <&i2spll_clk>;
+ #clock-cells = <0>;
+ };
+
clocks {
+ i2spll_clk: i2spll_clk {
+ compatible = "fixed-clock";
+ clock-frequency = <2700>;
+ #clock-cells = <0>;
+ };
+
i2cclk: i2cclk {
compatible = "fixed-clock";
clock-frequency = <5000>;
--
1.9.1
Re: [PATCH 1/2 v6] clk/axs10x: Add I2S PLL clock driver
Adding device tree mailing list and Rob Herring.
On 21-04-2016 18:19, Jose Abreu wrote:
> The ARC SDP I2S clock can be programmed using a
> specific PLL.
>
> This patch has the goal of adding a clock driver
> that programs this PLL.
>
> At this moment the rate values are hardcoded in
> a table but in the future it would be ideal to
> use a function which determines the PLL values
> given the desired rate.
>
> Signed-off-by: Jose Abreu
> ---
>
> Changes v5 -> v6:
> * Use parent clock to determine PLL input rate instead of using hardcoded
> values
> * Documentation update (added 'clocks' field)
>
> Changes v4 -> v5:
> * Documentation update (as suggested by Alexey Brodkin)
> * Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by
> Alexey Brodkin)
>
> Changes v3 -> v4:
> * Added binding document (as suggested by Stephen Boyd)
> * Minor code style fixes (as suggested by Stephen Boyd)
> * Use ioremap (as suggested by Stephen Boyd)
> * Implement round_rate (as suggested by Stephen Boyd)
> * Change to platform driver (as suggested by Stephen Boyd)
> * Use {readl/writel}_relaxed (as suggested by Vineet Gupta)
>
> Changes v2 -> v3:
> * Implemented recalc_rate
>
> Changes v1 -> v2:
> * Renamed folder to axs10x (as suggested by Alexey Brodkin)
> * Added more supported rates
>
> .../bindings/clock/axs10x-i2s-pll-clock.txt| 25 +++
> drivers/clk/Makefile | 1 +
> drivers/clk/axs10x/Makefile| 1 +
> drivers/clk/axs10x/i2s_pll_clock.c | 228
> +
> 4 files changed, 255 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
> create mode 100644 drivers/clk/axs10x/Makefile
> create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c
>
> diff --git a/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
> b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
> new file mode 100644
> index 000..5ffc8df
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
> @@ -0,0 +1,25 @@
> +Binding for the AXS10X I2S PLL clock
> +
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Required properties:
> +- compatible: shall be "snps,axs10x-i2s-pll-clock"
> +- reg : address and length of the I2S PLL register set.
> +- clocks: shall be the input parent clock phandle for the PLL.
> +- #clock-cells: from common clock binding; Should always be set to 0.
> +
> +Example:
> + pll_clock: pll_clock {
> + compatible = "fixed-clock";
> + clock-frequency = <2700>;
> + #clock-cells = <0>;
> + };
> +
> + i2s_clock@100a0 {
> + compatible = "snps,axs10x-i2s-pll-clock";
> + reg = <0x100a0 0x10>;
> + clocks = <&pll_clock>;
> + #clock-cells = <0>;
> + };
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 46869d6..2ca62dc6 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -84,3 +84,4 @@ obj-$(CONFIG_X86) += x86/
> obj-$(CONFIG_ARCH_ZX)+= zte/
> obj-$(CONFIG_ARCH_ZYNQ) += zynq/
> obj-$(CONFIG_H8300) += h8300/
> +obj-$(CONFIG_ARC_PLAT_AXS10X)+= axs10x/
> diff --git a/drivers/clk/axs10x/Makefile b/drivers/clk/axs10x/Makefile
> new file mode 100644
> index 000..01996b8
> --- /dev/null
> +++ b/drivers/clk/axs10x/Makefile
> @@ -0,0 +1 @@
> +obj-y += i2s_pll_clock.o
> diff --git a/drivers/clk/axs10x/i2s_pll_clock.c
> b/drivers/clk/axs10x/i2s_pll_clock.c
> new file mode 100644
> index 000..411310d
> --- /dev/null
> +++ b/drivers/clk/axs10x/i2s_pll_clock.c
> @@ -0,0 +1,228 @@
> +/*
> + * Synopsys AXS10X SDP I2S PLL clock driver
> + *
> + * Copyright (C) 2016 Synopsys
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* PLL registers addresses */
> +#define PLL_IDIV_REG 0x0
> +#define PLL_FBDIV_REG0x4
> +#define PLL_ODIV0_REG0x8
> +#define PLL_ODIV1_REG0xC
> +
> +struct i2s_pll_cfg {
> + unsigned int rate;
> + unsigned i
Re: [PATCH 2/2 v6] arc: axs10x: Add DT bindings for I2S PLL Clock
Adding device tree mailing list and Rob Herring.
On 21-04-2016 18:19, Jose Abreu wrote:
> Add device tree bindings for AXS10X I2S PLL Clock driver.
>
> Signed-off-by: Jose Abreu
> ---
>
> Changes v5 -> v6:
> * Added 'clocks' field
>
> This patch was only introduced in v5.
>
> arch/arc/boot/dts/axs10x_mb.dtsi | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi
> b/arch/arc/boot/dts/axs10x_mb.dtsi
> index ab5d570..5c6489e 100644
> --- a/arch/arc/boot/dts/axs10x_mb.dtsi
> +++ b/arch/arc/boot/dts/axs10x_mb.dtsi
> @@ -16,7 +16,20 @@
> ranges = <0x 0xe000 0x1000>;
> interrupt-parent = <&mb_intc>;
>
> + i2sclk: i2sclk@100a0 {
> + compatible = "snps,axs10x-i2s-pll-clock";
> + reg = <0x100a0 0x10>;
> + clocks = <&i2spll_clk>;
> + #clock-cells = <0>;
> + };
> +
> clocks {
> + i2spll_clk: i2spll_clk {
> + compatible = "fixed-clock";
> + clock-frequency = <2700>;
> + #clock-cells = <0>;
> + };
> +
> i2cclk: i2cclk {
> compatible = "fixed-clock";
> clock-frequency = <5000>;
[PATCH 0/5 v4] Add I2S/ADV7511 audio support for ARC AXS10x boards
ARC AXS10x platforms consist of a mainboard with several peripherals.
One of those peripherals is an HDMI output port controlled by the ADV7511
transmitter.
This patch set adds audio for the ADV7511 transmitter and I2S audio for
the AXS10x platform.
Changes v3 -> v4:
* Reintroduced custom PCM driver (see note below)
* Use DT boolean to switch between ALSA DMA engine PCM or custom PCM
* Use fifo depth to program I2S FCR
* Update I2S documentation
Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Removed HDMI start at adv7511_core (as suggested by Archit Taneja)
* Use NOP functions for adv7511_audio (as suggested by Archit Taneja)
* Added adv7511_audio_exit() function (as suggested by Archit Taneja)
* Moved adv7511 to its own folder (as suggested by Archit Taneja)
* Separated file rename of adv7511_core (as suggested by Emil Velikov)
* Compile adv7511 as module if ALSA SoC is compiled as module
* Load adv7511 audio only if declared in device tree (as suggested by Laurent
Pinchart)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S
Changes v1 -> v2:
* DT bindings moved to separate patch (as suggested by Alexey Brodkin)
* Removed defconfigs entries (as suggested by Alexey Brodkin)
NOTE:
Although the mainline I2S driver uses ALSA DMA engine,
this controller can be built without DMA support so it
was necessary to add this custom platform driver so that
HDMI audio works in AXS boards.
Jose Abreu (5):
drm/i2c/adv7511: Rename and move to separate folder
drm/i2c/adv7511: Add audio support
ASoC: dwc: Use fifo depth to program FCR
ASoC: dwc: Add custom PCM driver
ASoC: dwc: Update DOCUMENTATION for I2S Driver
.../bindings/display/bridge/adi,adv7511.txt| 3 +
.../devicetree/bindings/sound/designware-i2s.txt | 5 +
drivers/gpu/drm/i2c/Kconfig| 6 +-
drivers/gpu/drm/i2c/Makefile | 2 +-
drivers/gpu/drm/i2c/adv7511/Kconfig| 18 ++
drivers/gpu/drm/i2c/adv7511/Makefile | 3 +
drivers/gpu/drm/i2c/{ => adv7511}/adv7511.h| 53
drivers/gpu/drm/i2c/adv7511/adv7511_audio.c| 310 +
.../drm/i2c/{adv7511.c => adv7511/adv7511_core.c} | 43 +--
include/sound/soc-dai.h| 1 +
sound/soc/dwc/Kconfig | 9 +
sound/soc/dwc/Makefile | 1 +
sound/soc/dwc/designware.h | 70 +
sound/soc/dwc/designware_i2s.c | 106 +--
sound/soc/dwc/designware_pcm.c | 230 +++
15 files changed, 796 insertions(+), 64 deletions(-)
create mode 100644 drivers/gpu/drm/i2c/adv7511/Kconfig
create mode 100644 drivers/gpu/drm/i2c/adv7511/Makefile
rename drivers/gpu/drm/i2c/{ => adv7511}/adv7511.h (90%)
create mode 100644 drivers/gpu/drm/i2c/adv7511/adv7511_audio.c
rename drivers/gpu/drm/i2c/{adv7511.c => adv7511/adv7511_core.c} (97%)
create mode 100644 sound/soc/dwc/designware.h
create mode 100644 sound/soc/dwc/designware_pcm.c
--
1.9.1
[PATCH 3/5 v4] ASoC: dwc: Use fifo depth to program FCR
This patch makes Designware I2S driver use the fifo
depth value to program the fifo configuration register
instead of using hardcoded values.
Signed-off-by: Jose Abreu
---
This patch was only introduced in v4.
sound/soc/dwc/designware_i2s.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 3effcd1..0db69b7 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -100,6 +100,7 @@ struct dw_i2s_dev {
struct device *dev;
u32 ccr;
u32 xfer_resolution;
+ u32 fifo_th;
/* data related to DMA transfers b/w i2s and DMAC */
union dw_i2s_snd_dma_data play_dma_data;
@@ -232,14 +233,16 @@ static void dw_i2s_config(struct dw_i2s_dev *dev, int
stream)
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
i2s_write_reg(dev->i2s_base, TCR(ch_reg),
dev->xfer_resolution);
- i2s_write_reg(dev->i2s_base, TFCR(ch_reg), 0x02);
+ i2s_write_reg(dev->i2s_base, TFCR(ch_reg),
+ dev->fifo_th - 1);
irq = i2s_read_reg(dev->i2s_base, IMR(ch_reg));
i2s_write_reg(dev->i2s_base, IMR(ch_reg), irq & ~0x30);
i2s_write_reg(dev->i2s_base, TER(ch_reg), 1);
} else {
i2s_write_reg(dev->i2s_base, RCR(ch_reg),
dev->xfer_resolution);
- i2s_write_reg(dev->i2s_base, RFCR(ch_reg), 0x07);
+ i2s_write_reg(dev->i2s_base, RFCR(ch_reg),
+ dev->fifo_th - 1);
irq = i2s_read_reg(dev->i2s_base, IMR(ch_reg));
i2s_write_reg(dev->i2s_base, IMR(ch_reg), irq & ~0x03);
i2s_write_reg(dev->i2s_base, RER(ch_reg), 1);
@@ -499,6 +502,7 @@ static int dw_configure_dai(struct dw_i2s_dev *dev,
*/
u32 comp1 = i2s_read_reg(dev->i2s_base, dev->i2s_reg_comp1);
u32 comp2 = i2s_read_reg(dev->i2s_base, dev->i2s_reg_comp2);
+ u32 fifo_depth = 1 << (1 + COMP1_FIFO_DEPTH_GLOBAL(comp1));
u32 idx;
if (dev->capability & DWC_I2S_RECORD &&
@@ -537,6 +541,7 @@ static int dw_configure_dai(struct dw_i2s_dev *dev,
dev->capability |= DW_I2S_SLAVE;
}
+ dev->fifo_th = fifo_depth / 2;
return 0;
}
--
1.9.1
[PATCH 4/5 v4] ASoC: dwc: Add custom PCM driver
HDMI audio support was added to the AXS board using an
I2S cpu driver and a custom platform driver.
The platform driver supports two channels @ 16 bits with
rates 32k, 44.1k and 48k.
Although the mainline I2S driver uses ALSA DMA engine,
this controller can be built without DMA support so it
was necessary to add this custom platform driver so that
HDMI audio works in AXS boards.
The selection between the use of DMA engine or custom
PCM can be made using a device tree boolean parameter
which was introduced in this patch ('snps,use-dmaengine').
Signed-off-by: Jose Abreu
---
Changes v3 -> v4:
* Reintroduced custom PCM driver
* Use DT boolean to switch between ALSA DMA engine PCM or custom PCM
Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S
No changes v1 -> v2.
sound/soc/dwc/Kconfig | 9 ++
sound/soc/dwc/Makefile | 1 +
sound/soc/dwc/designware.h | 70 +
sound/soc/dwc/designware_i2s.c | 99 +-
sound/soc/dwc/designware_pcm.c | 230 +
5 files changed, 382 insertions(+), 27 deletions(-)
create mode 100644 sound/soc/dwc/designware.h
create mode 100644 sound/soc/dwc/designware_pcm.c
diff --git a/sound/soc/dwc/Kconfig b/sound/soc/dwc/Kconfig
index d50e085..2a21120 100644
--- a/sound/soc/dwc/Kconfig
+++ b/sound/soc/dwc/Kconfig
@@ -7,4 +7,13 @@ config SND_DESIGNWARE_I2S
Synopsys desigwnware I2S device. The device supports upto
maximum of 8 channels each for play and record.
+config SND_DESIGNWARE_PCM
+ tristate "Synopsys I2S PCM Driver"
+ help
+Say Y or M if you want to add support for ALSA ASoC platform driver
+using I2S.
+
+Select this option if you want to be able to create a sound interface
+using the I2S device driver as CPU driver. Instead of using ALSA
+DMA engine by selecting this driver a custom PCM driver will be used.
diff --git a/sound/soc/dwc/Makefile b/sound/soc/dwc/Makefile
index 319371f..1b48bccc 100644
--- a/sound/soc/dwc/Makefile
+++ b/sound/soc/dwc/Makefile
@@ -1,3 +1,4 @@
# SYNOPSYS Platform Support
obj-$(CONFIG_SND_DESIGNWARE_I2S) += designware_i2s.o
+obj-$(CONFIG_SND_DESIGNWARE_PCM) += designware_pcm.o
diff --git a/sound/soc/dwc/designware.h b/sound/soc/dwc/designware.h
new file mode 100644
index 000..196296c
--- /dev/null
+++ b/sound/soc/dwc/designware.h
@@ -0,0 +1,70 @@
+/*
+ * ALSA SoC Synopsys Audio Layer
+ *
+ * sound/soc/dwc/designware.h
+ *
+ * Copyright (C) 2016 Synopsys
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __DESIGNWARE_H
+#define __DESIGNWARE_H
+
+#include
+#include
+#include
+#include
+
+struct dw_pcm_binfo {
+ struct snd_pcm_substream *stream;
+ unsigned char *dma_base;
+ unsigned char *dma_pointer;
+ unsigned int period_size_frames;
+ unsigned int size;
+ snd_pcm_uframes_t period_pointer;
+ unsigned int total_periods;
+ unsigned int current_period;
+};
+
+union dw_i2s_snd_dma_data {
+ struct i2s_dma_data pd;
+ struct snd_dmaengine_dai_dma_data dt;
+};
+
+struct dw_i2s_dev {
+ void __iomem *i2s_base;
+ struct clk *clk;
+ int active;
+ unsigned int capability;
+ unsigned int quirks;
+ unsigned int i2s_reg_comp1;
+ unsigned int i2s_reg_comp2;
+ struct device *dev;
+ u32 ccr;
+ u32 xfer_resolution;
+ u32 fifo_th;
+
+ /* data related to DMA transfers b/w i2s and DMAC */
+ bool use_dmaengine;
+ union dw_i2s_snd_dma_data play_dma_data;
+ union dw_i2s_snd_dma_data capture_dma_data;
+ struct i2s_clk_config_data config;
+ int (*i2s_clk_cfg)(struct i2s_clk_config_data *config);
+ struct dw_pcm_binfo binfo;
+};
+
+#ifdef CONFIG_SND_DESIGNWARE_PCM
+int dw_pcm_transfer(u32 *lsample, u32 *rsample, int bytes, int buf_size,
+ struct dw_pcm_binfo *bi);
+#else
+int dw_pcm_transfer(u32 *lsample, u32 *rsample, int bytes, int buf_size,
+ struct dw_pcm_binfo *bi)
+{
+ return 0;
+}
+#endif
+
+#endif
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 0db69b7..16056c1 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include "designware.h"
/* common register for all channel */
#define IER0x000
@@ -84,31 +85,6 @@
#define MAX_CHANNEL_NUM8
#define MIN_CHANNEL_NUM2
-union dw_i2s_snd_dma_data {
- struct i2s_dma_data pd;
- struct snd_dmaengine_dai_dma_data dt;
-};
-
-struct dw_i2s_dev {
- void __iome
[PATCH 5/5 v4] ASoC: dwc: Update DOCUMENTATION for I2S Driver
This patch updates documentation for the Designware I2S driver. Signed-off-by: Jose Abreu --- This patch was only introduced in v4. Documentation/devicetree/bindings/sound/designware-i2s.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/designware-i2s.txt b/Documentation/devicetree/bindings/sound/designware-i2s.txt index 7bb5424..f3b5c17 100644 --- a/Documentation/devicetree/bindings/sound/designware-i2s.txt +++ b/Documentation/devicetree/bindings/sound/designware-i2s.txt @@ -7,6 +7,10 @@ Required properties: clocks. The controller expects one clock: the clock used as the sampling rate reference clock sample. - clock-names : "i2sclk" for the sample rate reference clock. + + Optional properties: + - snps,use-dmaengine: If set the driver will use ALSA DMA engine. If set + it is required to use the properties 'dmas' and 'dma-names'. - dmas: Pairs of phandle and specifier for the DMA channels that are used by the core. The core expects one or two dma channels: one for transmit and one for receive. @@ -26,6 +30,7 @@ Example: clocks = <&scpi_i2sclk 0>; clock-names = "i2sclk"; #sound-dai-cells = <0>; + snps,use-dmaengine; dmas = <&dma0 5>; dma-names = "tx"; }; -- 1.9.1
[PATCH 2/5 v4] drm/i2c/adv7511: Add audio support
This patch adds audio support for the ADV7511 HDMI transmitter
using ALSA SoC.
The code was ported from Analog Devices linux tree from
commit 1770c4a1e32b ("Merge remote-tracking branch
'xilinx/master' into xcomm_zynq"), which is available at:
- https://github.com/analogdevicesinc/linux/
The audio can be disabled using menu-config and/or device tree
so it is possible to use only video mode. The audio
(when enabled) registers as a codec into ALSA.
SPDIF DAI format was also added to ASoC as it is required
by adv7511 audio.
Signed-off-by: Jose Abreu
---
No changes v3 -> v4.
Changes v2 -> v3:
* Removed HDMI start at adv7511_core (as suggested by Archit Taneja)
* Use NOP functions for adv7511_audio (as suggested by Archit Taneja)
* Added adv7511_audio_exit() function (as suggested by Archit Taneja)
* Moved adv7511 to its own folder (as suggested by Archit Taneja)
* Compile adv7511 as module if ALSA SoC is compiled as module
* Load adv7511 audio only if declared in device tree (as suggested by Laurent
Pinchart)
No changes v1 -> v2.
.../bindings/display/bridge/adi,adv7511.txt| 3 +
drivers/gpu/drm/i2c/adv7511/Kconfig| 12 +
drivers/gpu/drm/i2c/adv7511/Makefile | 1 +
drivers/gpu/drm/i2c/adv7511/adv7511.h | 22 ++
drivers/gpu/drm/i2c/adv7511/adv7511_audio.c| 310 +
drivers/gpu/drm/i2c/adv7511/adv7511_core.c | 11 +
include/sound/soc-dai.h| 1 +
7 files changed, 360 insertions(+)
create mode 100644 drivers/gpu/drm/i2c/adv7511/adv7511_audio.c
diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 96c25ee..920e542 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -43,6 +43,9 @@ Optional properties:
data stream (similar to BT.656). Defaults to separate H/V synchronization
signals.
+- adi,enable-audio: If set the ADV7511 driver will register a codec interface
+ into ALSA SoC.
+
Required nodes:
The ADV7511 has two video ports. Their connections are modelled using the OF
diff --git a/drivers/gpu/drm/i2c/adv7511/Kconfig
b/drivers/gpu/drm/i2c/adv7511/Kconfig
index 302c8e34..900f3e9 100644
--- a/drivers/gpu/drm/i2c/adv7511/Kconfig
+++ b/drivers/gpu/drm/i2c/adv7511/Kconfig
@@ -4,3 +4,15 @@ config DRM_I2C_ADV7511
help
Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
+config DRM_I2C_ADV7511_AUDIO
+ bool "ADV7511 audio"
+ depends on DRM_I2C_ADV7511
+ depends on SND_SOC=y || (SND_SOC && DRM_I2C_ADV7511=m)
+ default y
+ help
+ This adds support for audio on the ADV7511(W) and ADV7513 HDMI
+ encoders.
+
+ By selecting this option the ADV7511 will register a codec interface
+ into ALSA.
+
diff --git a/drivers/gpu/drm/i2c/adv7511/Makefile
b/drivers/gpu/drm/i2c/adv7511/Makefile
index c13f5a1..d68773a 100644
--- a/drivers/gpu/drm/i2c/adv7511/Makefile
+++ b/drivers/gpu/drm/i2c/adv7511/Makefile
@@ -1,2 +1,3 @@
adv7511-y := adv7511_core.o
+adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/i2c/adv7511/adv7511.h
b/drivers/gpu/drm/i2c/adv7511/adv7511.h
index fcae1ee..35828f0 100644
--- a/drivers/gpu/drm/i2c/adv7511/adv7511.h
+++ b/drivers/gpu/drm/i2c/adv7511/adv7511.h
@@ -10,6 +10,7 @@
#define __DRM_I2C_ADV7511_H__
#include
+#include
#define ADV7511_REG_CHIP_REVISION 0x00
#define ADV7511_REG_N0 0x01
@@ -241,6 +242,7 @@ enum adv7511_sync_polarity {
* @sync_pulse:Select the sync pulse
* @vsync_polarity:vsync input signal configuration
* @hsync_polarity:hsync input signal configuration
+ * @enable_audio True if audio is enabled
*/
struct adv7511_link_config {
unsigned int input_color_depth;
@@ -255,6 +257,8 @@ struct adv7511_link_config {
enum adv7511_input_sync_pulse sync_pulse;
enum adv7511_sync_polarity vsync_polarity;
enum adv7511_sync_polarity hsync_polarity;
+
+ bool enable_audio;
};
/**
@@ -296,6 +300,10 @@ struct adv7511 {
bool powered;
unsigned int f_tmds;
+ unsigned int f_audio;
+
+ unsigned int audio_source;
+ bool enable_audio;
unsigned int current_edid_segment;
uint8_t edid_buf[256];
@@ -317,4 +325,18 @@ struct adv7511 {
int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet);
int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet);
+#ifdef CONFIG_DRM_I2C_ADV7511_AUDIO
+int adv7511_audio_init(struct device *dev);
+void adv7511_audio_exit(struct device *dev);
+#else
+int adv7511_audio_init(st
[PATCH 1/5 v4] drm/i2c/adv7511: Rename and move to separate folder
Main file of adv7511 driver was renamed from adv7511.c
to adv7511_core.c and moved to separate folder in order
to prepare the adding of audio support.
Struct adv7511 was moved to adv7511.h and functions
adv7511_packet_enable() and adv7511_packet_disable()
were made public also to prepare the adding of audio
support.
Signed-off-by: Jose Abreu
---
No changes v3 -> v4.
This patch was only introduced in v3.
drivers/gpu/drm/i2c/Kconfig| 6 +---
drivers/gpu/drm/i2c/Makefile | 2 +-
drivers/gpu/drm/i2c/adv7511/Kconfig| 6
drivers/gpu/drm/i2c/adv7511/Makefile | 2 ++
drivers/gpu/drm/i2c/{ => adv7511}/adv7511.h| 31 +
.../drm/i2c/{adv7511.c => adv7511/adv7511_core.c} | 32 ++
6 files changed, 43 insertions(+), 36 deletions(-)
create mode 100644 drivers/gpu/drm/i2c/adv7511/Kconfig
create mode 100644 drivers/gpu/drm/i2c/adv7511/Makefile
rename drivers/gpu/drm/i2c/{ => adv7511}/adv7511.h (93%)
rename drivers/gpu/drm/i2c/{adv7511.c => adv7511/adv7511_core.c} (97%)
diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 22c7ed6..9258daf 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -1,11 +1,7 @@
menu "I2C encoder or helper chips"
depends on DRM && DRM_KMS_HELPER && I2C
-config DRM_I2C_ADV7511
- tristate "AV7511 encoder"
- select REGMAP_I2C
- help
- Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
+source "drivers/gpu/drm/i2c/adv7511/Kconfig"
config DRM_I2C_CH7006
tristate "Chrontel ch7006 TV encoder"
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 2c72eb5..f144830 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -1,6 +1,6 @@
ccflags-y := -Iinclude/drm
-obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
+obj-y += adv7511/
ch7006-y := ch7006_drv.o ch7006_mode.o
obj-$(CONFIG_DRM_I2C_CH7006) += ch7006.o
diff --git a/drivers/gpu/drm/i2c/adv7511/Kconfig
b/drivers/gpu/drm/i2c/adv7511/Kconfig
new file mode 100644
index 000..302c8e34
--- /dev/null
+++ b/drivers/gpu/drm/i2c/adv7511/Kconfig
@@ -0,0 +1,6 @@
+config DRM_I2C_ADV7511
+ tristate "AV7511 encoder"
+ select REGMAP_I2C
+ help
+ Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
+
diff --git a/drivers/gpu/drm/i2c/adv7511/Makefile
b/drivers/gpu/drm/i2c/adv7511/Makefile
new file mode 100644
index 000..c13f5a1
--- /dev/null
+++ b/drivers/gpu/drm/i2c/adv7511/Makefile
@@ -0,0 +1,2 @@
+adv7511-y := adv7511_core.o
+obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/i2c/adv7511.h
b/drivers/gpu/drm/i2c/adv7511/adv7511.h
similarity index 93%
rename from drivers/gpu/drm/i2c/adv7511.h
rename to drivers/gpu/drm/i2c/adv7511/adv7511.h
index 38515b3..fcae1ee 100644
--- a/drivers/gpu/drm/i2c/adv7511.h
+++ b/drivers/gpu/drm/i2c/adv7511/adv7511.h
@@ -286,4 +286,35 @@ struct adv7511_video_config {
struct hdmi_avi_infoframe avi_infoframe;
};
+struct adv7511 {
+ struct i2c_client *i2c_main;
+ struct i2c_client *i2c_edid;
+
+ struct regmap *regmap;
+ struct regmap *packet_memory_regmap;
+ enum drm_connector_status status;
+ bool powered;
+
+ unsigned int f_tmds;
+
+ unsigned int current_edid_segment;
+ uint8_t edid_buf[256];
+ bool edid_read;
+
+ wait_queue_head_t wq;
+ struct drm_encoder *encoder;
+
+ bool embedded_sync;
+ enum adv7511_sync_polarity vsync_polarity;
+ enum adv7511_sync_polarity hsync_polarity;
+ bool rgb;
+
+ struct edid *edid;
+
+ struct gpio_desc *gpio_pd;
+};
+
+int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet);
+int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet);
+
#endif /* __DRM_I2C_ADV7511_H__ */
diff --git a/drivers/gpu/drm/i2c/adv7511.c
b/drivers/gpu/drm/i2c/adv7511/adv7511_core.c
similarity index 97%
rename from drivers/gpu/drm/i2c/adv7511.c
rename to drivers/gpu/drm/i2c/adv7511/adv7511_core.c
index a02112b..2b00581 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511/adv7511_core.c
@@ -20,34 +20,6 @@
#include "adv7511.h"
-struct adv7511 {
- struct i2c_client *i2c_main;
- struct i2c_client *i2c_edid;
-
- struct regmap *regmap;
- struct regmap *packet_memory_regmap;
- enum drm_connector_status status;
- bool powered;
-
- unsigned int f_tmds;
-
- unsigned int current_edid_segment;
- uint8_t edid_buf[256];
- bool edid_read;
-
- wait_queue_head_t wq;
- struct drm_encoder *encoder;
-
- bool embedded_sync;
- enum adv7511_sync_polarity vsync_polarity;
- enum adv7511_sync_polarity hsync_polarity;
- bool
Re: [PATCH 5/5 v4] ASoC: dwc: Update DOCUMENTATION for I2S Driver
Hi Mark, On 07-04-2016 18:53, Mark Brown wrote: > On Thu, Apr 07, 2016 at 05:53:59PM +0100, Jose Abreu wrote: > >> + Optional properties: >> + - snps,use-dmaengine: If set the driver will use ALSA DMA engine. If set >> + it is required to use the properties 'dmas' and 'dma-names'. > This is not a good interface, it's describing Linux internal APIs. If > the device needs to operate in PIO mode it should just do that. I added this interface because there is no direct way to check if DMA is available on the I2S controller so it is not possible to automatically change between DMA and PIO mode. As the I2S controller can be built with or without DMA support it is necessary to somehow check if DMA is enabled or not and according to that use either ALSA DMA engine or the custom platform driver sent in these patches. I did not want to remove drivers functionality so I added this property to the DT. This way a user can select between DMA and PIO mode. Is there a better option to do this without removing the possibility of using ALSA DMA engine in the driver? Best regards, Jose Miguel Abreu
Re: [alsa-devel] [PATCH 5/5 v4] ASoC: dwc: Update DOCUMENTATION for I2S Driver
Hi Lars, On 08-04-2016 16:52, Lars-Peter Clausen wrote: > On 04/08/2016 12:06 PM, Jose Abreu wrote: >> Hi Mark, >> >> >> On 07-04-2016 18:53, Mark Brown wrote: >>> On Thu, Apr 07, 2016 at 05:53:59PM +0100, Jose Abreu wrote: >>> >>>> + Optional properties: >>>> + - snps,use-dmaengine: If set the driver will use ALSA DMA engine. If set >>>> + it is required to use the properties 'dmas' and 'dma-names'. >>> This is not a good interface, it's describing Linux internal APIs. If >>> the device needs to operate in PIO mode it should just do that. >> I added this interface because there is no direct way to check if DMA is >> available on the I2S controller so it is not possible to automatically change >> between DMA and PIO mode. As the I2S controller can be built with or without >> DMA >> support it is necessary to somehow check if DMA is enabled or not and >> according >> to that use either ALSA DMA engine or the custom platform driver sent in >> these >> patches. I did not want to remove drivers functionality so I added this >> property >> to the DT. This way a user can select between DMA and PIO mode. > That's OK, but you need to describe the hardware, not the indented behavior > of the software driver. > Is this okay: "snps,use-dmaengine: Set this boolean paramater if I2S controller has DMA support. If set the properties 'dmas' and 'dma-names' must be also set" ? Best regards, Jose Miguel Abreu
Re: [alsa-devel] [PATCH 2/5 v4] drm/i2c/adv7511: Add audio support
Hi Lars,
On 08-04-2016 16:46, Lars-Peter Clausen wrote:
> On 04/07/2016 06:53 PM, Jose Abreu wrote:
>> This patch adds audio support for the ADV7511 HDMI transmitter
>> using ALSA SoC.
>>
>> The code was ported from Analog Devices linux tree from
>> commit 1770c4a1e32b ("Merge remote-tracking branch
>> 'xilinx/master' into xcomm_zynq"), which is available at:
>> - https://github.com/analogdevicesinc/linux/
> The reason why this driver is still out of tree, is because there has been
> no conclusion yet on how to go forward with the whole HDMI integration. So
> this is not going to get merged until that issue has been addressed.
Ok, will then drop the patches related with adv7511 but will update with your
comments so that when this HDMI issue is addressed I can send again the patches.
Is this okay?
>
> [...]
>> +- adi,enable-audio: If set the ADV7511 driver will register a codec
>> interface
>> + into ALSA SoC.
> This is not a description of the hardware.
Is this okay: "adi,enable-audio: Set this boolean parameter if ADV7511
transmitter routes audio signals" ?
>
> [...]
>> diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
>> index 964b7de..539c091 100644
>> --- a/include/sound/soc-dai.h
>> +++ b/include/sound/soc-dai.h
>> @@ -33,6 +33,7 @@ struct snd_compr_stream;
>> #define SND_SOC_DAIFMT_DSP_B5 /* L data MSB during FRM LRC
>> */
>> #define SND_SOC_DAIFMT_AC97 6 /* AC97 */
>> #define SND_SOC_DAIFMT_PDM 7 /* Pulse density modulation */
>> +#define SND_SOC_DAIFMT_SPDIF8 /* SPDIF */
> This needs to be a separate patch.
Ok.
>
>
> ___
> linux-snps-arc mailing list
> linux-snps-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Best regards,
Jose Miguel Abreu
Re: [alsa-devel] [PATCH 5/5 v4] ASoC: dwc: Update DOCUMENTATION for I2S Driver
Hi Lars, On 09-04-2016 15:55, Lars-Peter Clausen wrote: > On 04/08/2016 06:08 PM, Jose Abreu wrote: >> Hi Lars, >> >> >> On 08-04-2016 16:52, Lars-Peter Clausen wrote: >>> On 04/08/2016 12:06 PM, Jose Abreu wrote: >>>> Hi Mark, >>>> >>>> >>>> On 07-04-2016 18:53, Mark Brown wrote: >>>>> On Thu, Apr 07, 2016 at 05:53:59PM +0100, Jose Abreu wrote: >>>>> >>>>>> + Optional properties: >>>>>> + - snps,use-dmaengine: If set the driver will use ALSA DMA engine. If >>>>>> set >>>>>> + it is required to use the properties 'dmas' and 'dma-names'. >>>>> This is not a good interface, it's describing Linux internal APIs. If >>>>> the device needs to operate in PIO mode it should just do that. >>>> I added this interface because there is no direct way to check if DMA is >>>> available on the I2S controller so it is not possible to automatically >>>> change >>>> between DMA and PIO mode. As the I2S controller can be built with or >>>> without DMA >>>> support it is necessary to somehow check if DMA is enabled or not and >>>> according >>>> to that use either ALSA DMA engine or the custom platform driver sent in >>>> these >>>> patches. I did not want to remove drivers functionality so I added this >>>> property >>>> to the DT. This way a user can select between DMA and PIO mode. >>> That's OK, but you need to describe the hardware, not the indented behavior >>> of the software driver. >>> >> Is this okay: "snps,use-dmaengine: Set this boolean paramater if I2S >> controller >> has DMA support. If set the properties 'dmas' and 'dma-names' must be also >> set" ? > The description is better. But the name of the property is still imperative > rather then descriptive. It tells the software what should be done rather > then describing what the hardware looks like. > > Since there is already the dmas property which is present if a DMA is > connected and is absent when no DMA is present it should be enough to just > check that property rather than requiring an additional one. Ok, will then use the DMA property to decide which mode to use: PIO or DMA. > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel Best regards, Jose Miguel Abreu
Re: [alsa-devel] [PATCH 2/5 v4] drm/i2c/adv7511: Add audio support
Hi Lars, On 09-04-2016 16:02, Lars-Peter Clausen wrote: > On 04/08/2016 06:12 PM, Jose Abreu wrote: > [...] >>> [...] >>>> +- adi,enable-audio: If set the ADV7511 driver will register a codec >>>> interface >>>> + into ALSA SoC. >>> This is not a description of the hardware. >> Is this okay: "adi,enable-audio: Set this boolean parameter if ADV7511 >> transmitter routes audio signals" ? > I don't think we need this property. There is no problem with registering > the audio part unconditionally. As long as there is no connection we wont > create a sound card that is exposed to userspace. > This change was suggested by Laurent Pinchart and was introduced in v3. Quoting Laurent: "The idea is that enabling support for ADV7511 audio in the kernel isn't coupled with whether the system includes audio support. It would be confusing, and would also waste resources, to create a Linux sound device when no sound channel is routed on the board." Should I revert this? Best regards, Jose Miguel Abreu
[RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver
The ARC SDP I2S clock can be programmed using a
specific PLL.
This patch has the goal of adding a clock driver
that programs this PLL.
At this moment the rate values are hardcoded in
a table but in the future it would be ideal to
use a function which determines the PLL values
given the desired rate.
Signed-off-by: Jose Abreu
---
Changes v3 -> v4:
* Added binding document (as suggested by Stephen Boyd)
* Minor code style fixes (as suggested by Stephen Boyd)
* Use ioremap (as suggested by Stephen Boyd)
* Implement round_rate (as suggested by Stephen Boyd)
* Change to platform driver (as suggested by Stephen Boyd)
* Use {readl/writel}_relaxed (as suggested by Vineet Gupta)
Changes v2 -> v3:
* Implemented recalc_rate
Changes v1 -> v2:
* Renamed folder to axs10x (as suggested by Alexey Brodkin)
* Added more supported rates
.../devicetree/bindings/clock/i2s-pll-clock.txt| 17 ++
drivers/clk/Makefile | 1 +
drivers/clk/axs10x/Makefile| 1 +
drivers/clk/axs10x/i2s_pll_clock.c | 217 +
4 files changed, 236 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/i2s-pll-clock.txt
create mode 100644 drivers/clk/axs10x/Makefile
create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c
diff --git a/Documentation/devicetree/bindings/clock/i2s-pll-clock.txt
b/Documentation/devicetree/bindings/clock/i2s-pll-clock.txt
new file mode 100644
index 000..ff86a41
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/i2s-pll-clock.txt
@@ -0,0 +1,17 @@
+Binding for the AXS10X I2S PLL clock
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible: shall be "snps,i2s-pll-clock"
+- #clock-cells: from common clock binding; Should always be set to 0.
+- reg : Address and length of the I2S PLL register set.
+
+Example:
+ clock@0x100a0 {
+ compatible = "snps,i2s-pll-clock";
+ reg = <0x100a0 0x10>;
+ #clock-cells = <0>;
+ };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 46869d6..2ca62dc6 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -84,3 +84,4 @@ obj-$(CONFIG_X86) += x86/
obj-$(CONFIG_ARCH_ZX) += zte/
obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
obj-$(CONFIG_H8300)+= h8300/
+obj-$(CONFIG_ARC_PLAT_AXS10X) += axs10x/
diff --git a/drivers/clk/axs10x/Makefile b/drivers/clk/axs10x/Makefile
new file mode 100644
index 000..01996b8
--- /dev/null
+++ b/drivers/clk/axs10x/Makefile
@@ -0,0 +1 @@
+obj-y += i2s_pll_clock.o
diff --git a/drivers/clk/axs10x/i2s_pll_clock.c
b/drivers/clk/axs10x/i2s_pll_clock.c
new file mode 100644
index 000..3ba4e2f
--- /dev/null
+++ b/drivers/clk/axs10x/i2s_pll_clock.c
@@ -0,0 +1,217 @@
+/*
+ * Synopsys AXS10X SDP I2S PLL clock driver
+ *
+ * Copyright (C) 2016 Synopsys
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* FPGA Version Info */
+#define FPGA_VER_INFO 0xE0011230
+#define FPGA_VER_27M 0x000FBED9
+
+/* PLL registers addresses */
+#define PLL_IDIV_REG 0x0
+#define PLL_FBDIV_REG 0x4
+#define PLL_ODIV0_REG 0x8
+#define PLL_ODIV1_REG 0xC
+
+struct i2s_pll_cfg {
+ unsigned int rate;
+ unsigned int idiv;
+ unsigned int fbdiv;
+ unsigned int odiv0;
+ unsigned int odiv1;
+};
+
+static const struct i2s_pll_cfg i2s_pll_cfg_27m[] = {
+ /* 27 Mhz */
+ { 1024000, 0x104, 0x451, 0x10E38, 0x2000 },
+ { 1411200, 0x104, 0x596, 0x10D35, 0x2000 },
+ { 1536000, 0x208, 0xA28, 0x10B2C, 0x2000 },
+ { 2048000, 0x82, 0x451, 0x10E38, 0x2000 },
+ { 2822400, 0x82, 0x596, 0x10D35, 0x2000 },
+ { 3072000, 0x104, 0xA28, 0x10B2C, 0x2000 },
+ { 2116800, 0x82, 0x3CF, 0x10C30, 0x2000 },
+ { 2304000, 0x104, 0x79E, 0x10B2C, 0x2000 },
+ { 0, 0, 0, 0, 0 },
+};
+
+static const struct i2s_pll_cfg i2s_pll_cfg_28m[] = {
+ /* 28.224 Mhz */
+ { 1024000, 0x82, 0x105, 0x107DF, 0x2000 },
+ { 1411200, 0x28A, 0x1, 0x10001, 0x2000 },
+ { 1536000, 0xA28, 0x187, 0x10042, 0x2000 },
+ { 2048000, 0x41, 0x105, 0x107DF, 0x2000 },
+ { 2822400, 0x145, 0x1, 0x10001, 0x2000 },
+ { 3072000, 0x514, 0x187, 0x10042, 0x2000 },
+ { 2116800, 0x514, 0x42, 0x10001, 0x2000 },
+ { 2304000, 0x619, 0x82, 0x10001, 0x2000 },
+ { 0, 0, 0, 0, 0 },
+};
+
+struct i2s_pll_clk {
+ void __iomem *base;
+ struct clk_hw hw;
+ unsigned int ref_clk;
+ const struct i2s_pll_cfg *pll_cfg;
+};
+
+static inline void i2s_
Re: [alsa-devel] [PATCH 2/5 v4] drm/i2c/adv7511: Add audio support
Hi Lars,
On 11-04-2016 10:33, Lars-Peter Clausen wrote:
> On 04/11/2016 11:27 AM, Jose Abreu wrote:
>> Hi Lars,
>>
>>
>> On 09-04-2016 16:02, Lars-Peter Clausen wrote:
>>> On 04/08/2016 06:12 PM, Jose Abreu wrote:
>>> [...]
>>>>> [...]
>>>>>> +- adi,enable-audio: If set the ADV7511 driver will register a codec
>>>>>> interface
>>>>>> + into ALSA SoC.
>>>>> This is not a description of the hardware.
>>>> Is this okay: "adi,enable-audio: Set this boolean parameter if ADV7511
>>>> transmitter routes audio signals" ?
>>> I don't think we need this property. There is no problem with registering
>>> the audio part unconditionally. As long as there is no connection we wont
>>> create a sound card that is exposed to userspace.
>>>
>> This change was suggested by Laurent Pinchart and was introduced in v3.
>> Quoting
>> Laurent:
>> "The idea is that enabling support for ADV7511 audio in the kernel isn't
>> coupled
>> with whether the system includes audio support. It would be confusing, and
>> would
>> also waste resources, to create a Linux sound device when no sound channel is
>> routed on the board."
> I wouldn't care too much about this at this point, the extra amount of
> resources required for registering the CODEC (but not the sound card) is
> just a few bytes (sizeof(struct snd_soc_codec)).
>
> Nevertheless what we should do is describe the hardware and from this
> information infer whether there is a audio connection or not and if there is
> none we might skip registering the CODEC. In my opinion this hardware
> description should be modeled using of-graph, having a connection between
> the SoC side and the adv7511 SPDIF or I2S port.
>
You mean something like this:
sound_playback: sound_playback {
compatible = "simple-audio-card";
[...]
simple-audio-card,format = "i2s";
[...]
}
adv7511@xx {
compatible = "adi,adv7511";
[...]
ports {
[...]
/* Audio Output */
port@x {
reg = ;
endpoint {
remote-endpoint = <&sound_playback>;
}
}
}
}
?
Best regards,
Jose Miguel Abreu
Re: [PATCH 1/3 v2] drm/i2c/adv7511: Add audio support
Hi Laurent,
On 04-04-2016 22:41, Laurent Pinchart wrote:
> Hi Jose,
>
> On Monday 04 Apr 2016 10:05:39 Jose Abreu wrote:
>> On 01-04-2016 18:10, Laurent Pinchart wrote:
>>> On Monday 28 Mar 2016 15:36:09 Jose Abreu wrote:
>>>> This patch adds audio support for the ADV7511 HDMI transmitter
>>>> using ALSA SoC.
>>>>
>>>> The code was ported from Analog Devices linux tree from
>>>> commit 1770c4a1e32b ("Merge remote-tracking branch
>>>>
>>>> 'xilinx/master' into xcomm_zynq"), which is available at:
>>>>- https://github.com/analogdevicesinc/linux/
>>>>
>>>> The main core file was renamed from adv7511.c to adv7511_core.c
>>>> so that audio and video compile into a single adv7511.ko module
>>>> and to keep up with Analog Devices kernel tree.
>>>>
>>>> The audio can be disabled using menu-config so it is possible
>>>> to use only video mode.
>>>>
>>>> The HDMI mode is automatically started at boot and the audio
>>>> (when enabled) registers as a codec into ALSA.
>>>>
>>>> SPDIF DAI format was also added to ASoC as it is required
>>>> by adv7511 audio.
>>>>
>>>> Signed-off-by: Jose Abreu
>>>> ---
>>>>
>>>> No changes v1 -> v2.
>>>>
>>>> drivers/gpu/drm/i2c/Kconfig | 11 +
>>>> drivers/gpu/drm/i2c/Makefile|2 +
>>>> drivers/gpu/drm/i2c/adv7511.c | 1024
>>>> drivers/gpu/drm/i2c/adv7511.h | 41 ++
>>>> drivers/gpu/drm/i2c/adv7511_audio.c | 310 +++
>>>> drivers/gpu/drm/i2c/adv7511_core.c | 1005
>>> Please use git-format-patch -M to detect renames if you send a new version
>>> of this series, it will help with review.
>> Ok, will do that in next version.
>>
>>>> include/sound/soc-dai.h |1 +
>>>> 7 files changed, 1370 insertions(+), 1024 deletions(-)
>>>> delete mode 100644 drivers/gpu/drm/i2c/adv7511.c
>>>> create mode 100644 drivers/gpu/drm/i2c/adv7511_audio.c
>>>> create mode 100644 drivers/gpu/drm/i2c/adv7511_core.c
>>> [snip]
>>>
>>>> diff --git a/drivers/gpu/drm/i2c/adv7511_core.c
>>>> b/drivers/gpu/drm/i2c/adv7511_core.c new file mode 100644
>>>> index 000..d54256a
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/i2c/adv7511_core.c
>>> [snip]
>>>
>>>> +static int adv7511_probe(struct i2c_client *i2c, const struct
>>>> i2c_device_id *id) +{
>>>> + struct adv7511_link_config link_config;
>>>> + struct adv7511 *adv7511;
>>>> + struct device *dev = &i2c->dev;
>>>> + unsigned int val;
>>>> + int ret;
>>>> +
>>>> + if (!dev->of_node)
>>>> + return -EINVAL;
>>>> +
>>>> + adv7511 = devm_kzalloc(dev, sizeof(*adv7511), GFP_KERNEL);
>>>> + if (!adv7511)
>>>> + return -ENOMEM;
>>>> +
>>>> + adv7511->powered = false;
>>>> + adv7511->status = connector_status_disconnected;
>>>> +
>>>> + ret = adv7511_parse_dt(dev->of_node, &link_config);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + /*
>>>> + * The power down GPIO is optional. If present, toggle it from active
>>>> to
>>>> + * inactive to wake up the encoder.
>>>> + */
>>>> + adv7511->gpio_pd = devm_gpiod_get_optional(dev, "pd",
> GPIOD_OUT_HIGH);
>>>> + if (IS_ERR(adv7511->gpio_pd))
>>>> + return PTR_ERR(adv7511->gpio_pd);
>>>> +
>>>> + if (adv7511->gpio_pd) {
>>>> + mdelay(5);
>>>> + gpiod_set_value_cansleep(adv7511->gpio_pd, 0);
>>>> + }
>>>> +
>>>> + adv7511->regmap = devm_regmap_init_i2c(i2c, &adv7511_regmap_config);
>>>> + if (IS_ERR(adv7511->regmap))
>>>> + return PTR_ERR(adv7511->regmap);
>>>> +
>>>> + ret = regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, &val);
>>>> + if (ret)
>>>> + return ret;
>>>> + dev_dbg(dev, "Rev. %d\n", val);
>>>> +
>>>
[PATCH 2/3 v3] drm/i2c/adv7511: Add audio support
This patch adds audio support for the ADV7511 HDMI transmitter
using ALSA SoC.
The code was ported from Analog Devices linux tree from
commit 1770c4a1e32b ("Merge remote-tracking branch
'xilinx/master' into xcomm_zynq"), which is available at:
- https://github.com/analogdevicesinc/linux/
The audio can be disabled using menu-config so it is possible
to use only video mode. The audio (when enabled) registers as
a codec into ALSA.
SPDIF DAI format was also added to ASoC as it is required
by adv7511 audio.
Signed-off-by: Jose Abreu
---
.../bindings/display/bridge/adi,adv7511.txt| 3 +
drivers/gpu/drm/i2c/adv7511/Kconfig| 12 +
drivers/gpu/drm/i2c/adv7511/Makefile | 1 +
drivers/gpu/drm/i2c/adv7511/adv7511.h | 22 ++
drivers/gpu/drm/i2c/adv7511/adv7511_audio.c| 310 +
drivers/gpu/drm/i2c/adv7511/adv7511_core.c | 11 +
include/sound/soc-dai.h| 1 +
7 files changed, 360 insertions(+)
create mode 100644 drivers/gpu/drm/i2c/adv7511/adv7511_audio.c
diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 96c25ee..920e542 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -43,6 +43,9 @@ Optional properties:
data stream (similar to BT.656). Defaults to separate H/V synchronization
signals.
+- adi,enable-audio: If set the ADV7511 driver will register a codec interface
+ into ALSA SoC.
+
Required nodes:
The ADV7511 has two video ports. Their connections are modelled using the OF
diff --git a/drivers/gpu/drm/i2c/adv7511/Kconfig
b/drivers/gpu/drm/i2c/adv7511/Kconfig
index 302c8e34..900f3e9 100644
--- a/drivers/gpu/drm/i2c/adv7511/Kconfig
+++ b/drivers/gpu/drm/i2c/adv7511/Kconfig
@@ -4,3 +4,15 @@ config DRM_I2C_ADV7511
help
Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
+config DRM_I2C_ADV7511_AUDIO
+ bool "ADV7511 audio"
+ depends on DRM_I2C_ADV7511
+ depends on SND_SOC=y || (SND_SOC && DRM_I2C_ADV7511=m)
+ default y
+ help
+ This adds support for audio on the ADV7511(W) and ADV7513 HDMI
+ encoders.
+
+ By selecting this option the ADV7511 will register a codec interface
+ into ALSA.
+
diff --git a/drivers/gpu/drm/i2c/adv7511/Makefile
b/drivers/gpu/drm/i2c/adv7511/Makefile
index c13f5a1..d68773a 100644
--- a/drivers/gpu/drm/i2c/adv7511/Makefile
+++ b/drivers/gpu/drm/i2c/adv7511/Makefile
@@ -1,2 +1,3 @@
adv7511-y := adv7511_core.o
+adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/i2c/adv7511/adv7511.h
b/drivers/gpu/drm/i2c/adv7511/adv7511.h
index fcae1ee..35828f0 100644
--- a/drivers/gpu/drm/i2c/adv7511/adv7511.h
+++ b/drivers/gpu/drm/i2c/adv7511/adv7511.h
@@ -10,6 +10,7 @@
#define __DRM_I2C_ADV7511_H__
#include
+#include
#define ADV7511_REG_CHIP_REVISION 0x00
#define ADV7511_REG_N0 0x01
@@ -241,6 +242,7 @@ enum adv7511_sync_polarity {
* @sync_pulse:Select the sync pulse
* @vsync_polarity:vsync input signal configuration
* @hsync_polarity:hsync input signal configuration
+ * @enable_audio True if audio is enabled
*/
struct adv7511_link_config {
unsigned int input_color_depth;
@@ -255,6 +257,8 @@ struct adv7511_link_config {
enum adv7511_input_sync_pulse sync_pulse;
enum adv7511_sync_polarity vsync_polarity;
enum adv7511_sync_polarity hsync_polarity;
+
+ bool enable_audio;
};
/**
@@ -296,6 +300,10 @@ struct adv7511 {
bool powered;
unsigned int f_tmds;
+ unsigned int f_audio;
+
+ unsigned int audio_source;
+ bool enable_audio;
unsigned int current_edid_segment;
uint8_t edid_buf[256];
@@ -317,4 +325,18 @@ struct adv7511 {
int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet);
int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet);
+#ifdef CONFIG_DRM_I2C_ADV7511_AUDIO
+int adv7511_audio_init(struct device *dev);
+void adv7511_audio_exit(struct device *dev);
+#else
+int adv7511_audio_init(struct device *dev)
+{
+ return 0;
+}
+void adv7511_audio_exit(struct device *dev)
+{
+
+}
+#endif
+
#endif /* __DRM_I2C_ADV7511_H__ */
diff --git a/drivers/gpu/drm/i2c/adv7511/adv7511_audio.c
b/drivers/gpu/drm/i2c/adv7511/adv7511_audio.c
new file mode 100644
index 000..5562ed5
--- /dev/null
+++ b/drivers/gpu/drm/i2c/adv7511/adv7511_audio.c
@@ -0,0 +1,310 @@
+/*
+ * Analog Devices ADV7511 HDMI transmitter driver
+ *
+ * Copyright 2012 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include
+#in
[PATCH 0/3 v3] Add I2S/ADV7511 audio support for ARC AXS10x boards
ARC AXS10x platforms consist of a mainboard with several peripherals.
One of those peripherals is an HDMI output port controlled by the ADV7511
transmitter.
This patch set adds audio for the ADV7511 transmitter and I2S audio for
the AXS10x platform.
Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Removed HDMI start at adv7511_core (as suggested by Archit Taneja)
* Use NOP functions for adv7511_audio (as suggested by Archit Taneja)
* Added adv7511_audio_exit() function (as suggested by Archit Taneja)
* Moved adv7511 to its own folder (as suggested by Archit Taneja)
* Separated file rename of adv7511_core (as suggested by Emil Velikov)
* Compile adv7511 as module if ALSA SoC is compiled as module
* Load adv7511 audio only if declared in device tree (as suggested by Laurent
Pinchart)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S
Changes v1 -> v2:
* DT bindings moved to separate patch (as suggested by Alexey Brodkin)
* Removed defconfigs entries (as suggested by Alexey Brodkin)
Jose Abreu (3):
drm/i2c/adv7511: Rename and move to separate folder
drm/i2c/adv7511: Add audio support
ASoC: dwc: Unmask I2S interrupts only for enabled channels
.../bindings/display/bridge/adi,adv7511.txt| 3 +
drivers/gpu/drm/i2c/Kconfig| 6 +-
drivers/gpu/drm/i2c/Makefile | 2 +-
drivers/gpu/drm/i2c/adv7511/Kconfig| 18 ++
drivers/gpu/drm/i2c/adv7511/Makefile | 3 +
drivers/gpu/drm/i2c/{ => adv7511}/adv7511.h| 53
drivers/gpu/drm/i2c/adv7511/adv7511_audio.c| 310 +
.../drm/i2c/{adv7511.c => adv7511/adv7511_core.c} | 43 +--
include/sound/soc-dai.h| 1 +
sound/soc/dwc/designware_i2s.c | 5 +-
10 files changed, 406 insertions(+), 38 deletions(-)
create mode 100644 drivers/gpu/drm/i2c/adv7511/Kconfig
create mode 100644 drivers/gpu/drm/i2c/adv7511/Makefile
rename drivers/gpu/drm/i2c/{ => adv7511}/adv7511.h (90%)
create mode 100644 drivers/gpu/drm/i2c/adv7511/adv7511_audio.c
rename drivers/gpu/drm/i2c/{adv7511.c => adv7511/adv7511_core.c} (97%)
--
1.9.1
[PATCH 3/3 v3] ASoC: dwc: Unmask I2S interrupts only for enabled channels
There is no need to unmask all interrupts at I2S start. This
can cause performance issues in slower platforms.
Unmask only the interrupts for the used channels.
Signed-off-by: Jose Abreu
---
Changes v2 -> v3:
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S
* Removed pll_config functions (as suggested by Alexey Brodkin)
No changes v1 -> v2.
sound/soc/dwc/designware_i2s.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index bff258d..3effcd1 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -147,17 +147,18 @@ static inline void i2s_clear_irqs(struct dw_i2s_dev *dev,
u32 stream)
static void i2s_start(struct dw_i2s_dev *dev,
struct snd_pcm_substream *substream)
{
+ struct i2s_clk_config_data *config = &dev->config;
u32 i, irq;
i2s_write_reg(dev->i2s_base, IER, 1);
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
- for (i = 0; i < 4; i++) {
+ for (i = 0; i < (config->chan_nr / 2); i++) {
irq = i2s_read_reg(dev->i2s_base, IMR(i));
i2s_write_reg(dev->i2s_base, IMR(i), irq & ~0x30);
}
i2s_write_reg(dev->i2s_base, ITER, 1);
} else {
- for (i = 0; i < 4; i++) {
+ for (i = 0; i < (config->chan_nr / 2); i++) {
irq = i2s_read_reg(dev->i2s_base, IMR(i));
i2s_write_reg(dev->i2s_base, IMR(i), irq & ~0x03);
}
--
1.9.1
[PATCH 1/3 v3] drm/i2c/adv7511: Rename and move to separate folder
Main file of adv7511 driver was renamed from adv7511.c
to adv7511_core.c and moved to separate folder in order
to prepare the adding of audio support.
Struct adv7511 was moved to adv7511.h and functions
adv7511_packet_enable() and adv7511_packet_disable()
were made public also to prepare the adding of audio
support.
Signed-off-by: Jose Abreu
---
This patch was only introduced in v3.
drivers/gpu/drm/i2c/Kconfig| 6 +---
drivers/gpu/drm/i2c/Makefile | 2 +-
drivers/gpu/drm/i2c/adv7511/Kconfig| 6
drivers/gpu/drm/i2c/adv7511/Makefile | 2 ++
drivers/gpu/drm/i2c/{ => adv7511}/adv7511.h| 31 +
.../drm/i2c/{adv7511.c => adv7511/adv7511_core.c} | 32 ++
6 files changed, 43 insertions(+), 36 deletions(-)
create mode 100644 drivers/gpu/drm/i2c/adv7511/Kconfig
create mode 100644 drivers/gpu/drm/i2c/adv7511/Makefile
rename drivers/gpu/drm/i2c/{ => adv7511}/adv7511.h (93%)
rename drivers/gpu/drm/i2c/{adv7511.c => adv7511/adv7511_core.c} (97%)
diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 22c7ed6..9258daf 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -1,11 +1,7 @@
menu "I2C encoder or helper chips"
depends on DRM && DRM_KMS_HELPER && I2C
-config DRM_I2C_ADV7511
- tristate "AV7511 encoder"
- select REGMAP_I2C
- help
- Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
+source "drivers/gpu/drm/i2c/adv7511/Kconfig"
config DRM_I2C_CH7006
tristate "Chrontel ch7006 TV encoder"
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 2c72eb5..f144830 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -1,6 +1,6 @@
ccflags-y := -Iinclude/drm
-obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
+obj-y += adv7511/
ch7006-y := ch7006_drv.o ch7006_mode.o
obj-$(CONFIG_DRM_I2C_CH7006) += ch7006.o
diff --git a/drivers/gpu/drm/i2c/adv7511/Kconfig
b/drivers/gpu/drm/i2c/adv7511/Kconfig
new file mode 100644
index 000..302c8e34
--- /dev/null
+++ b/drivers/gpu/drm/i2c/adv7511/Kconfig
@@ -0,0 +1,6 @@
+config DRM_I2C_ADV7511
+ tristate "AV7511 encoder"
+ select REGMAP_I2C
+ help
+ Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
+
diff --git a/drivers/gpu/drm/i2c/adv7511/Makefile
b/drivers/gpu/drm/i2c/adv7511/Makefile
new file mode 100644
index 000..c13f5a1
--- /dev/null
+++ b/drivers/gpu/drm/i2c/adv7511/Makefile
@@ -0,0 +1,2 @@
+adv7511-y := adv7511_core.o
+obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/i2c/adv7511.h
b/drivers/gpu/drm/i2c/adv7511/adv7511.h
similarity index 93%
rename from drivers/gpu/drm/i2c/adv7511.h
rename to drivers/gpu/drm/i2c/adv7511/adv7511.h
index 38515b3..fcae1ee 100644
--- a/drivers/gpu/drm/i2c/adv7511.h
+++ b/drivers/gpu/drm/i2c/adv7511/adv7511.h
@@ -286,4 +286,35 @@ struct adv7511_video_config {
struct hdmi_avi_infoframe avi_infoframe;
};
+struct adv7511 {
+ struct i2c_client *i2c_main;
+ struct i2c_client *i2c_edid;
+
+ struct regmap *regmap;
+ struct regmap *packet_memory_regmap;
+ enum drm_connector_status status;
+ bool powered;
+
+ unsigned int f_tmds;
+
+ unsigned int current_edid_segment;
+ uint8_t edid_buf[256];
+ bool edid_read;
+
+ wait_queue_head_t wq;
+ struct drm_encoder *encoder;
+
+ bool embedded_sync;
+ enum adv7511_sync_polarity vsync_polarity;
+ enum adv7511_sync_polarity hsync_polarity;
+ bool rgb;
+
+ struct edid *edid;
+
+ struct gpio_desc *gpio_pd;
+};
+
+int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet);
+int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet);
+
#endif /* __DRM_I2C_ADV7511_H__ */
diff --git a/drivers/gpu/drm/i2c/adv7511.c
b/drivers/gpu/drm/i2c/adv7511/adv7511_core.c
similarity index 97%
rename from drivers/gpu/drm/i2c/adv7511.c
rename to drivers/gpu/drm/i2c/adv7511/adv7511_core.c
index a02112b..2b00581 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511/adv7511_core.c
@@ -20,34 +20,6 @@
#include "adv7511.h"
-struct adv7511 {
- struct i2c_client *i2c_main;
- struct i2c_client *i2c_edid;
-
- struct regmap *regmap;
- struct regmap *packet_memory_regmap;
- enum drm_connector_status status;
- bool powered;
-
- unsigned int f_tmds;
-
- unsigned int current_edid_segment;
- uint8_t edid_buf[256];
- bool edid_read;
-
- wait_queue_head_t wq;
- struct drm_encoder *encoder;
-
- bool embedded_sync;
- enum adv7511_sync_polarity vsync_polarity;
- enum adv7511_sync_polarity hsync_polarity;
- bool rgb;
-
- struct edid *edi
Re: [RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver
Hi Stephen,
On 16-04-2016 00:46, Stephen Boyd wrote:
> On 04/11, Jose Abreu wrote:
>> new file mode 100644
>> index 000..3ba4e2f
>> --- /dev/null
>> +++ b/drivers/clk/axs10x/i2s_pll_clock.c
>> @@ -0,0 +1,217 @@
>> +
>> +static int i2s_pll_clk_probe(struct platform_device *pdev)
>> +{
>> +struct device *dev = &pdev->dev;
>> +struct device_node *node = dev->of_node;
>> +const char *clk_name;
>> +struct clk *clk;
>> +struct i2s_pll_clk *pll_clk;
>> +struct clk_init_data init;
>> +struct resource *mem;
>> +
>> +if (!node)
>> +return -ENODEV;
> Does this ever happen? Looks like dead code.
Will remove.
>> +
>> +pll_clk = devm_kzalloc(dev, sizeof(*pll_clk), GFP_KERNEL);
>> +if (!pll_clk)
>> +return -ENOMEM;
>> +
>> +mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +pll_clk->base = devm_ioremap_resource(dev, mem);
>> +if (IS_ERR(pll_clk->base))
>> +return PTR_ERR(pll_clk->base);
>> +
>> +clk_name = node->name;
>> +init.name = clk_name;
>> +init.ops = &i2s_pll_ops;
>> +init.num_parents = 0;
>> +pll_clk->hw.init = &init;
>> +
>> +clk = clk_register(NULL, &pll_clk->hw);
> Pass dev as first argument. Also use devm_clk_register() instead.
Ok.
>> +if (IS_ERR(clk)) {
>> +dev_err(dev, "failed to register %s div clock (%ld)\n",
>> +clk_name, PTR_ERR(clk));
>> +return PTR_ERR(clk);
>> +}
>> +
>> +if (readl((void *)FPGA_VER_INFO) <= FPGA_VER_27M) {
> Please don't readl directly from addresses. I think I mentioned
> that before and didn't get back to you when you replied asking
> for other solutions. I still think a proper DT is in order
> instead of doing this check for ref_clk.
I think that the DT approach would be better but I also think that using two DT
files with only one change between them is not viable. I can see some
alternatives:
1) Pass the region of FPGA version in reg field of DT so that writel is not
directly used;
2) Create a dummy parent clock driver that reads from FPGA version register
and returns the rate;
3) Last resort: Use two DT files for each FPGA version.
@Vineet, @Alexey: Can you give some suggestions?
Some background:
We are expecting a new firmware release for the AXS board that will change the
reference clock value of the I2S PLL from 27MHz to 28.224MHz. Due to this change
the dividers of this PLL will change. Right now I am directly reading from the
FPGA version register but Stephen suggested to use a DT approach so that this
rate is declared as parent clock. This would be a good solution but would
require the usage of two different DT files (one for the current firmware and
another for the new firmware), which I think is not ideal. What is your opinion?
Some other solutions are listed above.
>> +pll_clk->ref_clk = 2700;
>> +pll_clk->pll_cfg = i2s_pll_cfg_27m;
>> +} else {
>> +pll_clk->ref_clk = 28224000;
>> +pll_clk->pll_cfg = i2s_pll_cfg_28m;
>> +}
> We should do this before registering the clk with the framework.
Ok.
>> +
>> +return of_clk_add_provider(node, of_clk_src_simple_get, clk);
>> +}
>> +
>> +static int i2s_pll_clk_remove(struct platform_device *pdev)
>> +{
>> +of_clk_del_provider(pdev->dev.of_node);
>> +return 0;
>> +}
>> +
>> +static const struct of_device_id i2s_pll_clk_id[] = {
>> +{ .compatible = "snps,i2s-pll-clock", },
>> +{ },
>> +};
>> +MODULE_DEVICE_TABLE(of, i2s_pll_clk_id);
>> +
>> +static struct platform_driver i2s_pll_clk_driver = {
>> +.driver = {
>> +.name = "i2s-pll-clock",
>> +.of_match_table = of_match_ptr(i2s_pll_clk_id),
> You can drop of_match_ptr(), it doesn't have much use besides
> introducing compilation warnings.
Ok.
>> +},
>> +.probe = i2s_pll_clk_probe,
>> +.remove = i2s_pll_clk_remove,
>> +};
>> +module_platform_driver(i2s_pll_clk_driver);
>>
Best regards,
Jose Miguel Abreu
