Re: [PATCH v5 1/3] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip
Hi lichenyang, On Sat, Sep 11, 2021 at 10:31:31AM +0800, lichenyang wrote: > From: Chenyang Li > > This patch adds an initial DRM driver for the Loongson LS7A1000 > bridge chip(LS7A). The LS7A bridge chip contains two display > controllers, support dual display output. The maximum support for > each channel display is to 1920x1080@60Hz. > At present, DC device detection and DRM driver registration are > completed, the crtc/plane/encoder/connector objects has been > implemented. > On Loongson 3A4000 CPU and 7A1000 system, we have achieved the use > of dual screen, and support dual screen clone mode and expansion > mode. > > v11: > - Remove a lot of useless code. > - Add help information. > - Delete unnecessary header files. Looks much better now, thanks. Can you provide some kind of overview of the HW? It is confusing that you talk about a bridge for a display driver - is this something from the HW? And please look into usign the drm_bridge_connector - as this is what any modern DRM display driver needs to use today. Also the connector type needs to be specified - unknown is not acceptable here. The mail you sent did not show up at https://lore.kernel.org/dri-devel/ Please fix what is required to make it visible there. This is where we point people to see the original mails. Also a cover letter that explains what has been done - and what has not been done - would be nice. I look forward to v12, Sam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 3/3] drm/loongson: Add interrupt driver for LS7A
Hi lichenyang, On Fri, Jul 30, 2021 at 05:41:48PM +0800, lichenyang wrote: > Add LS7A DC vsync interrupt enable and close function, and > register irq_handler function interface. > Add vbrank event processing flow. s/vbrank/vblank/ > > v4: > - Replace drm_irq_install with devm_request_irq. > - Delete the irq_ hooks in drm_driver. > > v3: > - Improve code readability. > - Use the to_pci_dev function to get pci_dev. > > v2: > - Added error handling in the loongson_drm_load function. > > Signed-off-by: lichenyang Patch looks good, Acked-by: Sam Ravnborg But then I am not to fluent in the vblank stuff, so I hope someone else takes a look too. Sam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 2/3] drm/loongson: Add GPIO and I2C driver for loongson drm.
Hi lichenyang,
On Fri, Jul 30, 2021 at 05:41:47PM +0800, lichenyang wrote:
> Implement use GPIO and I2C driver to detect connector
> and fetch EDID via DDC.
>
> v3:
> - Change some driver log to the drm_ version.
>
> v2:
> - Optimize the error handling process.
> - Delete loongson_i2c_bus_match and loongson_i2c_add function.
> - Optimize part of the code flow.
>
> Signed-off-by: lichenyang
Thanks for keeping me in the loop on this patch series.
In general the code looks pretty clean and well structured which makes
review easier - good.
As already said this driver should be implemented as a bridge which
would make the integration with the display driver simpler and more
straightforward.
When implementing this as a bridge driver there will be no drm_device,
so logging will need to use dev_err and friends.
Try to run the driver(s) with sparse:
make C=2 drivers/gpu/drm/loongson/
I think this will give you a few warnigns to fix.
Likewise use checkpatch --strict as this often resutls in a few easy to
fix warnings.
Last try to build with W=1 and fix warnings too.
The above goes for all files in this driver as we would like to have all
new drivers W=1, sparse and checkpatch clean.
Some more specific comments in the following,
Sam
> ---
> drivers/gpu/drm/loongson/Makefile | 1 +
> drivers/gpu/drm/loongson/loongson_connector.c | 59 -
> drivers/gpu/drm/loongson/loongson_drv.c | 15 +-
> drivers/gpu/drm/loongson/loongson_drv.h | 11 +
> drivers/gpu/drm/loongson/loongson_i2c.c | 249 ++
> drivers/gpu/drm/loongson/loongson_i2c.h | 36 +++
> 6 files changed, 366 insertions(+), 5 deletions(-)
> create mode 100644 drivers/gpu/drm/loongson/loongson_i2c.c
> create mode 100644 drivers/gpu/drm/loongson/loongson_i2c.h
>
> diff --git a/drivers/gpu/drm/loongson/Makefile
> b/drivers/gpu/drm/loongson/Makefile
> index d73ad44fe1d5..a842e85cf6ca 100644
> --- a/drivers/gpu/drm/loongson/Makefile
> +++ b/drivers/gpu/drm/loongson/Makefile
> @@ -10,5 +10,6 @@ loongson-y := loongson_connector.o \
> loongson_device.o \
> loongson_drv.o \
> loongson_encoder.o \
> + loongson_i2c.o \
> loongson_plane.o
> obj-$(CONFIG_DRM_LOONGSON) += loongson.o
> diff --git a/drivers/gpu/drm/loongson/loongson_connector.c
> b/drivers/gpu/drm/loongson/loongson_connector.c
> index a4762d8f9987..bdf7d651d6d1 100644
> --- a/drivers/gpu/drm/loongson/loongson_connector.c
> +++ b/drivers/gpu/drm/loongson/loongson_connector.c
> @@ -4,12 +4,56 @@
>
> static int loongson_get_modes(struct drm_connector *connector)
> {
> - int count;
> + struct drm_device *dev = connector->dev;
> + struct loongson_connector *lconnector =
> + to_loongson_connector(connector);
> + struct i2c_adapter *adapter = lconnector->i2c->adapter;
> + struct edid *edid = NULL;
> + u32 ret;
>
> - count = drm_add_modes_noedid(connector, 1920, 1080);
> - drm_set_preferred_mode(connector, 1024, 768);
> + edid = drm_get_edid(connector, adapter);
> + if (edid) {
> + drm_connector_update_edid_property(connector, edid);
> + ret = drm_add_edid_modes(connector, edid);
> + } else {
> + drm_warn(dev, "Failed to read EDID\n");
> + ret = drm_add_modes_noedid(connector, 1920, 1080);
> + drm_set_preferred_mode(connector, 1024, 768);
> + }
>
> - return count;
> + return ret;
> +}
> +
> +static bool is_connected(struct loongson_connector *lconnector)
> +{
> + struct i2c_adapter *adapter = lconnector->i2c->adapter;
> + unsigned char start = 0x0;
> + struct i2c_msg msgs = {
> + .addr = DDC_ADDR,
> + .flags = 0,
> + .len = 1,
> + .buf = ,
> + };
> +
> + if (!lconnector->i2c)
> + return false;
> +
> + if (i2c_transfer(adapter, , 1) != 1)
> + return false;
> +
> + return true;
> +}
> +
> +static enum drm_connector_status
> +loongson_detect(struct drm_connector *connector, bool force)
> +{
> + struct loongson_connector *lconnector =
> + to_loongson_connector(connector);
> +
> + if (is_connected(lconnector))
> + return connector_status_connected;
> +
> + return connector_status_disconnected;
> }
>
> static const struct drm_connector_helper_funcs loongson_connector_helper = {
> @@ -17,6 +61,7 @@ static const struct drm_connector_helper_funcs
> loongson_connector_helper = {
> };
>
> static const struct drm_connector_funcs loongson_connector_funcs =
Re: [PATCH v1 1/1] drm/bridge: anx7625: Tune K value for IVO panel
On Thu, Aug 05, 2021 at 03:30:55PM +0800, Xin Ji wrote: > IVO panel require less input video clock variation than video clock > variation in DP CTS spec. > > This patch decreases the K value of ANX7625 which will shrink eDP Tx > video clock variation to meet IVO panel's requirement. > > Signed-off-by: Xin Ji Looks good, I assume someone else (Robert) picks this. Acked-by: Sam Ravnborg Sam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/3] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip
Hi Chenyang, some feedback in the following. I will try to find more time for review during the week. Hi Thomas, please see my question near drm_gem_vram_of_gem(). Sam On Fri, Jul 30, 2021 at 05:41:46PM +0800, lichenyang wrote: > From: Chenyang Li > > This patch adds an initial DRM driver for the Loongson LS7A1000 > bridge chip(LS7A). The LS7A bridge chip contains two display > controllers, support dual display output. The maximum support for > each channel display is to 1920x1080@60Hz. > At present, DC device detection and DRM driver registration are > completed, the crtc/plane/encoder/connector objects has been > implemented. > On Loongson 3A4000 CPU and 7A1000 system, we have achieved the use > of dual screen, and support dual screen clone mode and expansion > mode. > > v10: > - Replace the drmm_ version functions. > - Replace the simple_encoder version function. > - Alphabetize file names. > > v9: > - Optimize the error handling process. > - Remove the useless flags parameter. > - Fix some incorrect use of variables and constructs. > > v8: > - Update the atomic_update function interface. > > v7: > - The pixel clock is limited to less than 173000. > > v6: > - Remove spin_lock in mmio reg read and write. > - TO_UNCAC is replac with ioremap. > - Fix error arguments in crtc_atomic_enable/disable/mode_valid. > > v5: > - Change the name of the chip to LS7A. > - Change magic value in crtc to macros. > - Correct mistakes words. > - Change the register operation function prefix to ls7a. > > v4: > - Move the mode_valid function to the crtc. > > v3: > - Move the mode_valid function to the connector and optimize it. > - Fix num_crtc calculation method. > > v2: > - Complete the case of 32-bit color in CRTC. > > Signed-off-by: Chenyang Li > --- > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/loongson/Kconfig | 14 + > drivers/gpu/drm/loongson/Makefile | 14 + > drivers/gpu/drm/loongson/loongson_connector.c | 47 +++ > drivers/gpu/drm/loongson/loongson_crtc.c | 238 +++ > drivers/gpu/drm/loongson/loongson_device.c| 35 +++ > drivers/gpu/drm/loongson/loongson_drv.c | 271 ++ > drivers/gpu/drm/loongson/loongson_drv.h | 149 ++ > drivers/gpu/drm/loongson/loongson_encoder.c | 21 ++ > drivers/gpu/drm/loongson/loongson_plane.c | 92 ++ > 11 files changed, 884 insertions(+) > create mode 100644 drivers/gpu/drm/loongson/Kconfig > create mode 100644 drivers/gpu/drm/loongson/Makefile > create mode 100644 drivers/gpu/drm/loongson/loongson_connector.c > create mode 100644 drivers/gpu/drm/loongson/loongson_crtc.c > create mode 100644 drivers/gpu/drm/loongson/loongson_device.c > create mode 100644 drivers/gpu/drm/loongson/loongson_drv.c > create mode 100644 drivers/gpu/drm/loongson/loongson_drv.h > create mode 100644 drivers/gpu/drm/loongson/loongson_encoder.c > create mode 100644 drivers/gpu/drm/loongson/loongson_plane.c > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 7ff89690a976..08562d9be6e3 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -365,6 +365,8 @@ source "drivers/gpu/drm/xen/Kconfig" > > source "drivers/gpu/drm/vboxvideo/Kconfig" > > +source "drivers/gpu/drm/loongson/Kconfig" > + > source "drivers/gpu/drm/lima/Kconfig" Preferably in alphabetical order, so after lima. > > source "drivers/gpu/drm/panfrost/Kconfig" > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index a118692a6df7..29c05b8cf2ad 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -119,6 +119,7 @@ obj-$(CONFIG_DRM_PL111) += pl111/ > obj-$(CONFIG_DRM_TVE200) += tve200/ > obj-$(CONFIG_DRM_XEN) += xen/ > obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/ > +obj-$(CONFIG_DRM_LOONGSON) += loongson/ > obj-$(CONFIG_DRM_LIMA) += lima/ Likewise, after lima > obj-$(CONFIG_DRM_PANFROST) += panfrost/ > obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/ > diff --git a/drivers/gpu/drm/loongson/Kconfig > b/drivers/gpu/drm/loongson/Kconfig > new file mode 100644 > index ..3cf42a4cca08 > --- /dev/null > +++ b/drivers/gpu/drm/loongson/Kconfig > @@ -0,0 +1,14 @@ > +# SPDX-License-Identifier: GPL-2.0-only > + > +config DRM_LOONGSON > + tristate "DRM support for LS7A bridge chipset" > + depends on DRM && PCI > + depends on CPU_LOONGSON64 Maybe add || COMPILE_TEST - so we get better build coverage. You risk we miss this driver when we do refa
Re: [PATCH v4 2/3] drm/loongson: Add GPIO and I2C driver for loongson drm.
Hi lichenyang, On Fri, Jul 30, 2021 at 05:41:47PM +0800, lichenyang wrote: > Implement use GPIO and I2C driver to detect connector > and fetch EDID via DDC. > > v3: > - Change some driver log to the drm_ version. > > v2: > - Optimize the error handling process. > - Delete loongson_i2c_bus_match and loongson_i2c_add function. > - Optimize part of the code flow. > > Signed-off-by: lichenyang I will return later with more detailed feedback. One high-level comment is that all the i2c support would be much better modelled as a bridge. And then you could use the bridge_connector. Sam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/3] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip
Hi Chenyang, I browsed the code on lore and noticed a few things and thought it better to bring it to your attention now. The general structure of the drivers seems good and coding style is fine. The feedback is mostly stuff we have decided to do different over time, so likely because you based the driver on some older driver. And it can be hard to follow all the refactoring going on - something that you get for free (almost) when is is mainlined. 1) Use drm_ for logging whereever possible (need drm_device) 2) Do not use irq mid-layer support in drm_driver, it is about to be legacy only. In other words avoid using drm_irq* stuff. 3) Look at drm_drv to see code snippet how to use the drmm* infrastructure. It will save you some cleanup and in general make the driver more stable 4) Sort includes alphabetically, and split them on in blocks. is one block is next block 5) Put entry in makefile in alphabetical order 6) You most like can use the simple_encoder stuff we have today 7) The *_load and *_unlod names where used in the past. Maybe be inspired by some newer driver here. _load functiosn is something used by legacy drivers so it confuses me a little. I look forward to see next revision of the patch-set. And sorry for not providing these high-level feedback issues before - I have not had time to look at your driver. Sam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/3] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip
On Fri, Jul 23, 2021 at 10:57:56AM +0200, Daniel Vetter wrote: > On Fri, Jul 23, 2021 at 11:12:49AM +0800, lichenyang wrote: > > From: Chenyang Li > > > > This patch adds an initial DRM driver for the Loongson LS7A1000 > > bridge chip(LS7A). The LS7A bridge chip contains two display > > controllers, support dual display output. The maximum support for > > each channel display is to 1920x1080@60Hz. > > At present, DC device detection and DRM driver registration are > > completed, the crtc/plane/encoder/connector objects has been > > implemented. > > On Loongson 3A4000 CPU and 7A1000 system, we have achieved the use > > of dual screen, and support dual screen clone mode and expansion > > mode. > > > > v9: > > - Optimize the error handling process. > > - Remove the useless flags parameter. > > - Fix some incorrect use of variables and constructs. > > ... > > Somehow this simple driver is at v9 and still not landed. Do you have > someone from the drm maintainers/committers who's guiding you through all > this? I'm not seeing you Cc: a specific person, without that there's good > chances your contribution gets lost. I'm swamped myself, which is why I've > ignored this and hope you'd fine someone else and stick to them. Hi Chenyang, Please cc: me on the next revision - then I will take a look. But I count on someone more familiar with atomic modesetting can also take a look. Thomas? Maxime? Sam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 000/141] Fix fall-through warnings for Clang
Hi James. > > > If none of the 140 patches here fix a real bug, and there is no > > > change to machine code then it sounds to me like a W=2 kind of a > > > warning. > > > > FWIW, this series has found at least one bug so far: > > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=kr...@mail.gmail.com/ > > > Well, it's a problem in an error leg, sure, but it's not a really > compelling reason for a 141 patch series, is it? All that fixing this > error will do is get the driver to print "oh dear there's a problem" > under four more conditions than it previously did. You are asking the wrong question here. Yuo should ask how many hours could have been saved by all the bugs people have been fighting with and then fixed *before* the code hit the kernel at all. My personal experience is that I, more than once, have had errors related to a missing break in my code. So this warnings is IMO a win. And if we are only ~100 patches to have it globally enabled then it is a no-brainer in my book. Sam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v17 0/2] Add initial support for slimport anx7625
Hi Xin Ji On Fri, Sep 18, 2020 at 06:18:19PM +0800, Xin Ji wrote: > Hi all, > > The following series add support for the Slimport ANX7625 transmitter, a > ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable > device. Thanks for all the iterations on this series. Driver looks good and I have applied it to drm-misc-next. Expect it to appear in -next in a few weeks. Sam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/49] DRM driver for Hikey 970
Hi Mauro.
Laurent and I discussed this driver a little on irc.
Some highlights:
This parts could use register names:
+ writel(0x2, noc_dss_base + 0xc);
+ writel(0x2, noc_dss_base + 0x8c);
+ writel(0x2, noc_dss_base + 0x10c);
+ writel(0x2, noc_dss_base + 0x18c);
The two nodes in the DT for DPE and DSI uses overlapping range for reg
entries. It looks like a syscon node or some iommu thing is needed to do
this properly.
The chain will lok like this:
DPE -> DSI -> video mux -> {adv7533, panel}
But drm_bridge has not yet support for such non-linear setup.
The recommendation is to focus on the HDMI prat. Then we can later
come up with support for a video mux.
The video mux should have a dedicated node with one input node and two
output nodes. Which is also where the gpio should be.
The DSI node references two DPHY instances - should it be PHY driver(s)?
Does the DSI part contain one or two instances. Clocks looks duplicated.
Does the DPE and DSI share a lot of register blocks - or does it just
look like this from a first point of view?
You can read though the logs here:
https://people.freedesktop.org/~cbrill/dri-log/index.php
Could you please try to get back on some of the points above so we can
help you move forward in the right direction.
Thanks,
Sam
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/49] DRM driver for Hikey 970
Hi Mauro
> Before posting the big patch series again, let me send the new
> version folded into a single patch.
>
> If you'd like to see the entire thing, I'm placing it here:
>
>
> https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/hikey970_v2/
Review 3/3
For next submission then to ease review it would be nice that the patch
is spilt up a little. Maybe something like:
- HW specific stuff in two patches (header fiels with register + setup
code)
- Display driver files
- DSI driver files
- build stuff (Makefile, Kconfig fragments)
So all splits on file level - which should be easy to do.
This will make it easier for more people to give feedback. It is a bit
much to walk through 4k loc or what the full size is.
And then we can also provide a-b or r-b for fragments so the reviewed
parts can be ignored for later reviews.
For the DSI parts I may be hit by the old "when you have a hammer then
everything looks like a nail syndrome".
In my case the hammer is the bridge interface.
Suggestions:
- Move encoder to display driver
- Move connector creation to display driver (using
drm_bridge_connector_init())
- Use drm_bridge interface for the DSI driver parts
- Maybe use the HDMI bridge driver as a chained driver - I did not look
to close on this
- Use the standard bridge interface to find the bridge and drop use of
the component framework
I hope that some other drm people chime in here.
Either to tell this is non-sense or confirm this is the way to go.
The above does not give any hint how to use the gpio_mux to shift
between the panel and HDMI. This logic needs to be in the display driver
as the bridge driver will only be used for HDMI - as I understand the
code. And I do not know how to do it.
Some details in the following that are not related to the above.
Sam
> diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
> b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
> new file mode 100644
> index ..a2eed961b7d5
> --- /dev/null
> +++ b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
> @@ -0,0 +1,2126 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DesignWare MIPI DSI Host Controller v1.02 driver
> + *
> + * Copyright (c) 2016 Linaro Limited.
> + * Copyright (c) 2014-2016 Hisilicon Limited.
> + * Copyright (c) 2014-2020, Huawei Technologies Co., Ltd
> + *
> + * Author:
> + *
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Sort
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Sort
> +
> +#include "kirin9xx_dw_dsi_reg.h"
> +#include "kirin9xx_dpe.h"
> +#include "kirin9xx_drm_drv.h"
> +#include "kirin9xx_drm_dpe_utils.h"
Sort
> +
> +#define PHY_REF_CLK_RATE 1920
> +#define PHY_REF_CLK_PERIOD_PS(10 / (PHY_REF_CLK_RATE / 1000))
> +
> +#define encoder_to_dsi(encoder) \
> + container_of(encoder, struct dw_dsi, encoder)
> +#define host_to_dsi(host) \
> + container_of(host, struct dw_dsi, host)
> +#define connector_to_dsi(connector) \
> + container_of(connector, struct dw_dsi, connector)
Move the upcast next to the struct definition.
> +#define DSS_REDUCE(x)((x) > 0 ? ((x) - 1) : (x))
> +
> +enum dsi_output_client {
> + OUT_HDMI = 0,
> + OUT_PANEL,
> + OUT_MAX
> +};
> +
> +struct mipi_phy_params {
I did not check all fiels but I managed to find at least one unused
field. Cheack and delete what is unused.
> + u64 lane_byte_clk;
> + u32 clk_division;
> +
> + u32 clk_lane_lp2hs_time;
> + u32 clk_lane_hs2lp_time;
> + u32 data_lane_lp2hs_time;
> + u32 data_lane_hs2lp_time;
> + u32 clk2data_delay;
> + u32 data2clk_delay;
> +
> + u32 clk_pre_delay;
> + u32 clk_post_delay;
> + u32 clk_t_lpx;
> + u32 clk_t_hs_prepare;
> + u32 clk_t_hs_zero;
> + u32 clk_t_hs_trial;
> + u32 clk_t_wakeup;
> + u32 data_pre_delay;
> + u32 data_post_delay;
> + u32 data_t_lpx;
> + u32 data_t_hs_prepare;
> + u32 data_t_hs_zero;
> + u32 data_t_hs_trial;
> + u32 data_t_ta_go;
> + u32 data_t_ta_get;
> + u32 data_t_wakeup;
> +
> + u32 phy_stop_wait_time;
> +
> + u32 rg_vrefsel_vcm;
> + u32 rg_hstx_ckg_sel;
> + u32 rg_pll_fbd_div5f;
> + u32 rg_pll_fbd_div1f;
> + u32 rg_pll_fbd_2p;
> + u32 rg_pll_enbwt;
> + u32 rg_pll_fbd_p;
> + u32 rg_pll_fbd_s;
> + u32 rg_pll_pre_div1p;
> + u32 rg_pll_pre_p;
> + u32 rg_pll_vco_750m;
> + u32 rg_pll_lpf_rs;
Re: [PATCH 00/49] DRM driver for Hikey 970
Hi Mauro
> Before posting the big patch series again, let me send the new
> version folded into a single patch.
Review 2/N
The way output_poll_changed is used to set gpio_mux to select between
the panel and the HDMI looks strange. But I do not know if there is a
more correct way to do it. Other DRM people would need to help
here if there is a better way to do it.
I looked briefly af suspend/resume.
I think this would benefit from using drm_mode_config_helper_suspend()
and drm_mode_config_helper_resume() but I did not finalize the anlyzis.
Other than this only some small details in the following.
Sam
> kirin9xx_drm_drv.c b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
> new file mode 100644
> index ..61b65f8b1ace
> --- /dev/null
> +++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
> @@ -0,0 +1,277 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Hisilicon Kirin SoCs drm master driver
> + *
> + * Copyright (c) 2016 Linaro Limited.
> + * Copyright (c) 2014-2016 Hisilicon Limited.
> + * Copyright (c) 2014-2020, Huawei Technologies Co., Ltd
> + * Author:
> + *
> + *
> + */
> +
> +#include
> +#include
> +#include
Sort includes
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Sort includes
> +
> +#include "kirin9xx_dpe.h"
> +#include "kirin9xx_drm_drv.h"
> +
> +static int kirin_drm_kms_cleanup(struct drm_device *dev)
> +{
> + struct kirin_drm_private *priv = to_drm_private(dev);
> +
> + if (priv->fbdev)
> + priv->fbdev = NULL;
> +
> + drm_kms_helper_poll_fini(dev);
> + kirin9xx_dss_drm_cleanup(dev);
> +
> + return 0;
> +}
> +
> +static void kirin_fbdev_output_poll_changed(struct drm_device *dev)
> +{
> + struct kirin_drm_private *priv = to_drm_private(dev);
> +
> + dsi_set_output_client(dev);
> +
> + drm_fb_helper_hotplug_event(priv->fbdev);
> +}
> +
> +static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
> + .fb_create = drm_gem_fb_create,
> + .output_poll_changed = kirin_fbdev_output_poll_changed,
> + .atomic_check = drm_atomic_helper_check,
> + .atomic_commit = drm_atomic_helper_commit,
> +};
> +
> +static int kirin_drm_kms_init(struct drm_device *dev)
> +{
> + long kirin_type;
> + int ret;
> +
> + dev_set_drvdata(dev->dev, dev);
> +
> + ret = drmm_mode_config_init(dev);
> + if (ret)
> + return ret;
> +
> + dev->mode_config.min_width = 0;
> + dev->mode_config.min_height = 0;
> + dev->mode_config.max_width = 2048;
> + dev->mode_config.max_height = 2048;
> + dev->mode_config.preferred_depth = 32;
> +
> + dev->mode_config.funcs = _drm_mode_config_funcs;
> +
> + /* display controller init */
> + kirin_type = (long)of_device_get_match_data(dev->dev);
> + if (WARN_ON(!kirin_type))
> + return -ENODEV;
> +
> + ret = dss_drm_init(dev, kirin_type);
> + if (ret)
> + return ret;
> +
> + /* bind and init sub drivers */
> + ret = component_bind_all(dev->dev, dev);
> + if (ret) {
> + drm_err(dev, "failed to bind all component.\n");
> + return ret;
> + }
> +
> + /* vblank init */
> + ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
> + if (ret) {
> + drm_err(dev, "failed to initialize vblank.\n");
> + return ret;
> + }
> + /* with irq_enabled = true, we can use the vblank feature. */
> + dev->irq_enabled = true;
> +
> + /* reset all the states of crtc/plane/encoder/connector */
> + drm_mode_config_reset(dev);
> +
> + /* init kms poll for handling hpd */
> + drm_kms_helper_poll_init(dev);
> +
> + return 0;
> +}
> +
> +DEFINE_DRM_GEM_CMA_FOPS(kirin_drm_fops);
Move it to right above kirin_drm_driver where it is used
> +
> +static int kirin_drm_connectors_register(struct drm_device *dev)
> +{
> + struct drm_connector_list_iter conn_iter;
> + struct drm_connector *failed_connector;
> + struct drm_connector *connector;
> + int ret;
> +
> + mutex_lock(>mode_config.mutex);
> + drm_connector_list_iter_begin(dev, _iter);
> + drm_for_each_connector_iter(connector, _iter) {
> + ret = drm_connector_register(connector);
> + if (ret) {
> + failed_connector = connector;
> + goto err;
> + }
> + }
> +
Re: [PATCH 00/49] DRM driver for Hikey 970
Hi Mauro > kirin9xx_fb_panel.h b/drivers/staging/hikey9xx/gpu/kirin9xx_fb_panel.h > new file mode 100644 > index ..a69c20470f1d > --- /dev/null > +++ b/drivers/staging/hikey9xx/gpu/kirin9xx_fb_panel.h This file is not referenced and should be deleted. Sam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/49] DRM driver for Hikey 970
Hi Mauro.
> Before posting the big patch series again, let me send the new
> version folded into a single patch.
Review 1/N
Lots of small details I missed last time.
A good thing is that there is an opportunity to delete som more code.
Sam
> diff --git a/drivers/staging/hikey9xx/gpu/Kconfig
> b/drivers/staging/hikey9xx/gpu/Kconfig
> new file mode 100644
> index ..8578ca953785
> --- /dev/null
> +++ b/drivers/staging/hikey9xx/gpu/Kconfig
> @@ -0,0 +1,10 @@
> +config DRM_HISI_KIRIN9XX
> + tristate "DRM Support for Hisilicon Kirin9xx series SoCs Platform"
> + depends on DRM && OF && ARM64
> + select DRM_KMS_HELPER
> + select DRM_GEM_CMA_HELPER
> + select DRM_KMS_CMA_HELPER
> + select DRM_MIPI_DSI
> + help
> + Choose this option if you have a HiSilicon Kirin960 or Kirin970.
> + If M is selected the module will be called kirin9xx-drm.
> diff --git a/drivers/staging/hikey9xx/gpu/Makefile
> b/drivers/staging/hikey9xx/gpu/Makefile
> new file mode 100644
> index ..5f7974a95367
> --- /dev/null
> +++ b/drivers/staging/hikey9xx/gpu/Makefile
> @@ -0,0 +1,8 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +kirin9xx-drm-y := kirin9xx_drm_drv.o \
> + kirin9xx_drm_dss.o \
> + kirin9xx_drm_dpe_utils.o \
> + kirin970_defs.o kirin960_defs.o \
> + kirin9xx_drm_overlay_utils.o
> +
> +obj-$(CONFIG_DRM_HISI_KIRIN9XX) += kirin9xx-drm.o kirin9xx_dw_drm_dsi.o
General comment which is true for many many Makefile's
I have never understood the love of '\'.
Something like this works equally well:
kirin9xx-drm-y := kirin9xx_drm_drv.o kirin9xx_drm_dss.o
kirin9xx-drm-y += kirin9xx_drm_dpe_utils.o kirin970_defs.o
kirin9xx-drm-y += kirin960_defs.o kirin9xx_drm_overlay_utils.o
obj-$(CONFIG_DRM_HISI_KIRIN9XX) += kirin9xx-drm.o kirin9xx_dw_drm_dsi.o
> diff --git a/drivers/staging/hikey9xx/gpu/kirin960_defs.c
> b/drivers/staging/hikey9xx/gpu/kirin960_defs.c
> new file mode 100644
> index ..c5e1ec03c818
> --- /dev/null
> +++ b/drivers/staging/hikey9xx/gpu/kirin960_defs.c
> @@ -0,0 +1,346 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2008-2011, Hisilicon Tech. Co., Ltd. All rights reserved.
> + * Copyright (c) 2008-2020, Huawei Technologies Co., Ltd
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "kirin9xx_drm_dpe_utils.h"
> +#include "kirin9xx_drm_drv.h"
> +#include "kirin960_dpe_reg.h"
All includes blocks should be sorted.
The list of include files looks far too large for this simple file.
Reduce to the relevant include files.
> +
> +static const u32
> kirin960_g_dss_module_base[DSS_CHN_MAX_DEFINE][MODULE_CHN_MAX] = {
> + {
> + /* D0 */
> + MIF_CH0_OFFSET,
> + AIF0_CH0_OFFSET,
> + AIF1_CH0_OFFSET,
> + MCTL_CTL_MUTEX_RCH0,
> + DSS_MCTRL_SYS_OFFSET + MCTL_RCH0_FLUSH_EN,
> + DSS_MCTRL_SYS_OFFSET + MCTL_RCH0_OV_OEN,
> + DSS_MCTRL_SYS_OFFSET + MCTL_RCH0_STARTY,
> + DSS_MCTRL_SYS_OFFSET + MCTL_MOD0_DBG,
> + DSS_RCH_D0_DMA_OFFSET,
> + DSS_RCH_D0_DFC_OFFSET,
> + 0,
> + 0,
> + 0,
> + 0,
> + 0,
> + 0,
> + DSS_RCH_D0_CSC_OFFSET,
> + }, {
...
> + },
> +};
> +
> +static const u32
> kirin960_g_dss_module_ovl_base[DSS_MCTL_IDX_MAX][MODULE_OVL_MAX] = {
> + {
> + DSS_OVL0_OFFSET,
> + DSS_MCTRL_CTL0_OFFSET
> + }, {
> + DSS_OVL1_OFFSET,
> + DSS_MCTRL_CTL1_OFFSET
> + }, {
> + DSS_OVL2_OFFSET,
> + DSS_MCTRL_CTL2_OFFSET,
> + }, {
> + DSS_OVL3_OFFSET,
> + DSS_MCTRL_CTL3_OFFSET,
> + }, {
> + 0,
> + DSS_MCTRL_CTL4_OFFSET,
> + }, {
> + 0,
> + DSS_MCTRL_CTL5_OFFSET,
> + }
> +};
> +
> +/* SCF_LUT_CHN coef_idx */
> +static const int kirin960_g_scf_lut_chn_coef_idx[DSS_CHN_MAX_DEFINE] = {
> + -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1
> +};
> +
> +static const u32
> kirin960_g_dss_module_cap[DSS_CHN_MAX_DEFINE][MODULE_CAP_MAX] = {
> + /* D2 */
> + {0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 1},
> + /* D3 */
> + {0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1},
> + /* V0 */
> + {0, 1, 1, 0, 1, 1, 1, 0, 0, 1, 1},
> + /* G0 */
> + {0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0},
> + /*
Re: [PATCH 00/49] DRM driver for Hikey 970
Hi Mauro. On Fri, Aug 21, 2020 at 04:41:58PM +0200, Mauro Carvalho Chehab wrote: > Another quick question: > > Em Wed, 19 Aug 2020 19:35:58 +0200 > Sam Ravnborg escreveu: > > > > +#define DSS_REDUCE(x)((x) > 0 ? ((x) - 1) : (x)) > > Use generic macros for this? > > Do you know a generic macro similar to this? Or do you mean adding > it to include/kernel.h? It looked like something there should be a macro for. But I do not know one. And no, do not try to go the kernel.h route on this. At least not until you see more than one user. Sam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/49] DRM driver for Hikey 970
Hi Mauro.
Thanks for the detailed feedabck.
Two comments in the following.
Sam
>
> > > + ctx->dss_pri_clk = devm_clk_get(dev, "clk_edc0");
> > > + if (!ctx->dss_pri_clk) {
> > > + DRM_ERROR("failed to parse dss_pri_clk\n");
> > > + return -ENODEV;
> > > + }
> ...
>
> > I had expected some of these could fail with a PROBE_DEFER.
> > Consider to use the newly introduced dev_probe_err()
>
> Yeah, getting clock lines can fail. I was unable to find dev_probe_err(),
> at least on Kernel 5.9-rc1. I saw this comment:
>
> https://lkml.org/lkml/2020/3/6/356
>
> It sounds it didn't reach upstream. Anyway, I add error handling for the
> the clk_get calls:
>
> ctx->dss_pri_clk = devm_clk_get(dev, "clk_edc0");
> ret = PTR_ERR_OR_ZERO(ctx->dss_pri_clk);
> if (ret == -EPROBE_DEFER) {
> return ret;
> } else if (ret) {
> DRM_ERROR("failed to parse dss_pri_clk: %d\n", ret);
> return ret;
> }
>
> This should be able to detect deferred probe, plus to warn
> about other errors.
I got the name wrong. It is named dev_err_probe(), and was introduced in -rc1.
> > Can the panel stuff be moved out and utilise drm_panel?
>
> I saw the code at drm_panel. The real issue here is that I can't
> test anything related to panel support, as I lack any hardware
> for testing. So, there's a high chance I may end breaking
> something while trying to do that.
I will try to take a look again when you post next revision.
Maybe we should update it and risk that is not works, so whenever
someone try to fix it they do so on top of an up-to-date implmentation.
Lets se and decide later.
Sam
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/49] DRM driver for Hikey 970
Hi Mauro.
Quick feedback below.
Sam
On Thu, Aug 20, 2020 at 05:13:22PM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 20 Aug 2020 16:48:08 +0200
> Sam Ravnborg escreveu:
>
> > Hi Mauro.
> >
> > On Thu, Aug 20, 2020 at 04:06:49PM +0200, Mauro Carvalho Chehab wrote:
> > > Em Wed, 19 Aug 2020 19:35:58 +0200
> > > Sam Ravnborg escreveu:
> > >
> > > I'm already handling the other comments from your review (I'll send a
> > > more complete comment about them after finishing),
> > If you get back only on things you do not understand or do not agree on
> > that would be fine. The rest should be visible in the changelog on the
> > updated patch - no need to do extra work here.
> >
> > > but I have a doubt what you meant about this:
> > >
> > > > +static int kirin_drm_bind(struct device *dev)
> > > > > +{
> > > > > + struct drm_driver *driver = _drm_driver;
> > > > > + struct drm_device *drm_dev;
> > > > > + struct kirin_drm_private *priv;
> > > > > + int ret;
> > > > > +
> > > > > + drm_dev = drm_dev_alloc(driver, dev);
> > > > > + if (!drm_dev)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + ret = kirin_drm_kms_init(drm_dev);
> > > > > + if (ret)
> > > > > + goto err_drm_dev_unref;
> > > > > +
> > > > > + ret = drm_dev_register(drm_dev, 0);
> > > > There is better ways to do this. See drm_drv.c for the code example.
> > >
> > > Not sure if I understood your comment here. The drm_drv.c example also
> > > calls
> > > drm_dev_register().
> >
> > This is indeed not obvious from my comments but what I wnated to say is
> > that the driver should embed drm_device in some struct,
> > maybe in "struct kirin_drm_private".
> >
> > This should also be part of the referenced example.
> >
> > I hope this clarifies it.
>
> Yeah. I was already doing those changes ;-)
>
> Something like the enclosed patch, right?
>
> Btw, I'm not sure if the error handling part is ok, as I didn't check
> what the devm stuff does at the subsystem.
>
> -
>
> On a separate question, I was unable to use the helper macros,
> as it sounds that there's no macro with this:
>
> .dumb_create= drm_gem_cma_dumb_create_internal,
>
> The existing DRM_GEM_CMA_VMAP_DRIVER_OPS uses, instead
> drm_gem_cma_dumb_create(). I'm not sure if this driver can use
> such function instead.
>From the documentation of drm_gem_cma_dumb_create_internal:
* It should not be used directly
* as their _driver.dumb_create callback.
I would expect drm_gem_cma_dumb_create() to be the right choice.
So you can go ahead with DRM_GEM_CMA_VMAP_DRIVER_OPS
(I hope I am right, not the are i know much about)
> staging: hikey9xx/gpu: use drm_managed interface
>
> Use a more modern design for the driver binding logic by
> using drm_managed and getting rid of drm->dev_private.
>
> Signed-off-by: Mauro Carvalho Chehab
>
> diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
> b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
> index c7736f4d74b7..600c89605cc0 100644
> --- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
> +++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
> @@ -29,12 +29,13 @@
> #include
> #include
> #include
> +#include
>
> #include "kirin9xx_drm_drv.h"
>
> static int kirin_drm_kms_cleanup(struct drm_device *dev)
> {
> - struct kirin_drm_private *priv = dev->dev_private;
> + struct kirin_drm_private *priv = to_drm_private(dev);
> static struct kirin_dc_ops const *dc_ops;
>
> if (priv->fbdev)
> @@ -45,15 +46,13 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
> drm_kms_helper_poll_fini(dev);
> dc_ops->cleanup(dev);
> drm_mode_config_cleanup(dev);
This should also be gone when you are using
drmm_mode_config_init()
> - devm_kfree(dev->dev, priv);
> - dev->dev_private = NULL;
>
> return 0;
> }
>
> static void kirin_fbdev_output_poll_changed(struct drm_device *dev)
> {
> - struct kirin_drm_private *priv = dev->dev_private;
> + struct kirin_drm_private *priv = to_drm_private(dev);
>
> dsi_set_output_client(dev);
>
> @@ -69,18 +68,20 @@ static const struct drm_mode_config_funcs
> kirin_drm_mode_config_funcs = {
>
> static int kirin_drm_kms_init(stru
Re: [PATCH 00/49] DRM driver for Hikey 970
Hi Mauro.
On Thu, Aug 20, 2020 at 04:06:49PM +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 19 Aug 2020 19:35:58 +0200
> Sam Ravnborg escreveu:
>
> I'm already handling the other comments from your review (I'll send a
> more complete comment about them after finishing),
If you get back only on things you do not understand or do not agree on
that would be fine. The rest should be visible in the changelog on the
updated patch - no need to do extra work here.
> but I have a doubt what you meant about this:
>
> > +static int kirin_drm_bind(struct device *dev)
> > > +{
> > > + struct drm_driver *driver = _drm_driver;
> > > + struct drm_device *drm_dev;
> > > + struct kirin_drm_private *priv;
> > > + int ret;
> > > +
> > > + drm_dev = drm_dev_alloc(driver, dev);
> > > + if (!drm_dev)
> > > + return -ENOMEM;
> > > +
> > > + ret = kirin_drm_kms_init(drm_dev);
> > > + if (ret)
> > > + goto err_drm_dev_unref;
> > > +
> > > + ret = drm_dev_register(drm_dev, 0);
> > There is better ways to do this. See drm_drv.c for the code example.
>
> Not sure if I understood your comment here. The drm_drv.c example also calls
> drm_dev_register().
This is indeed not obvious from my comments but what I wnated to say is
that the driver should embed drm_device in some struct,
maybe in "struct kirin_drm_private".
This should also be part of the referenced example.
I hope this clarifies it.
Sam
>
> The only difference is that it calls it inside driver_probe(), while
> on this driver, it uses:
>
> static const struct component_master_ops kirin_drm_ops = {
> .bind = kirin_drm_bind,
> .unbind = kirin_drm_unbind,
> };
>
> static int kirin_drm_platform_probe(struct platform_device *pdev)
> {
> ...
> drm_of_component_match_add(dev, , compare_of, remote);
> ...
> return component_master_add_with_match(dev, _drm_ops, match);
> }
>
> Are you meaning that I should get rid of this component API and call
> kirin_drm_bind() from kirin_drm_platform_probe()?
>
> Thanks,
> Mauro
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/49] DRM driver for Hikey 970
Hi John. > > So, IMO, the best is to keep it on staging for a while, until those > > remaining bugs gets solved. > > I'm not sure I see all of these as compelling for pushing it in via > staging. And I suspect in the process of submitting the patches for > review folks may find the cause of some of the problems you list here. There is a tendency to forget drivers in staging, and with the almost constant refactoring that happens in the drm drivers we would end up fixing this driver when a bot trigger an error. So IMO we need very good reasons to go in via staging. Sam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v14 0/2] Add initial support for slimport anx7625
Hi Xin Ji. On Mon, Aug 10, 2020 at 10:35:46PM +0200, Sam Ravnborg wrote: > Hi Xin Ji. > > On Thu, Jul 09, 2020 at 04:31:09PM +0800, Xin Ji wrote: > > Hi all, > > > > The following series add support for the Slimport ANX7625 transmitter, a > > ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable > > device. > > > > > > This is the v14 version, any mistakes, please let me know, I will fix it in > > the next series. > > > > Change history: > > v14: Fix comments from Sam and Nicolas > > - Check flags at drm_bridge_attach > > - Use panel_bridge instead of drm_panel > > - Fix not correct return value > > Sorry for ignoring this for so long time. > The patch applies but no longer builds. > > I could fix it locally but wanted to know if you have a later version to > be applied? I took a short look at the driver today. I noticed following code: if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) return -EINVAL; So if the display driver do not supply the DRM_BRIDGE_ATTACH_NO_CONNECTOR then -EINVAL is returned. But then the anx7625_bridge_attach() continues and creates a connector. For a new bridge driver there should be no need for the backward compatibility - so no need to create the connector. Unless the display driver needs it - but then we should fix the display driver and not add backward compatibility code in the bridge driver. Which display driver do you expect this bridge driver to be used with? Sam > > Sam > > > > > > v13: Fix comments from Launrent Pinchart and Rob Herring > > - Picked up Rob's Reviewed-By > > - Add .detect and .get_edid interface in bridge funcs. > > > > v12: Fix comments from Hsin-Yi Wang > > - Rebase the code on kernel 5.7, fix DRM interface not match issue. > > > > v11: Fix comments from Rob Herring > > - Update commit message. > > - Remove unused label. > > > > v10: Fix comments from Rob Herring, Daniel. > > - Fix dt_binding_check warning. > > - Update description. > > > > v9: Fix comments from Sam, Nicolas, Daniel > > - Remove extcon interface. > > - Remove DPI support. > > - Fix dt_binding_check complains. > > - Code clean up and update description. > > > > v8: Fix comments from Nicolas. > > - Fix several coding format. > > - Update description. > > > > v7: > > - Fix critical timing(eg:odd hfp/hbp) in "mode_fixup" interface, > >enhance MIPI RX tolerance by setting register MIPI_DIGITAL_ADJ_1 to 0x3D. > > > > > > Xin Ji (2): > > dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema > > drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP > > > > .../bindings/display/bridge/analogix,anx7625.yaml | 95 + > > drivers/gpu/drm/bridge/analogix/Kconfig|9 + > > drivers/gpu/drm/bridge/analogix/Makefile |1 + > > drivers/gpu/drm/bridge/analogix/anx7625.c | 1939 > > > > drivers/gpu/drm/bridge/analogix/anx7625.h | 391 > > 5 files changed, 2435 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c > > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h > > > > -- > > 2.7.4 > > > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/49] DRM driver for Hikey 970
tem > staging: hikey9xx/gpu: get rid of typedefs > staging: hikey9xx/gpu: get rid of input/output macros > staging: hikey9xx/gpu: get rid of some unused data > staging: hikey9xx/gpu: place common definitions at kirin9xx_dpe.h > staging: hikey9xx/gpu: get rid of DRM_HISI_KIRIN970 > dts: hisilicon: hi3670.dtsi: add I2C settings > dts: hikey970-pinctrl.dtsi: add missing pinctrl settings > dt: hisilicon: add support for the PMIC found on Hikey 970 > dts: add support for Hikey 970 DRM > staging: hikey9xx/gpu: drop kirin9xx_pwm > dt: display: Add binds for the DPE and DSI controller for Kirin > 960/970 > > Xiubin Zhang (7): > staging: hikey9xx/gpu: add support to hikey970 HDMI and panel > staging: hikey9xx/gpu: Solve SR Cannot Display Problems. > staging: hikey9xx/gpu: Solve HDMI compatibility Problem. > staging: hikey9xx/gpu: Support MIPI DSI 3 lanes for hikey970. > staging: hikey9xx/gpu: Solve SR test reset problem for hikey970. > staging: hikey9xx/gpu: add debug prints for this driver > staging: hikey9xx/gpu: Add support 10.1 inch special HDMI displays. > > .../display/hisilicon,hi3660-dpe.yaml | 99 + > .../display/hisilicon,hi3660-dsi.yaml | 102 + > .../boot/dts/hisilicon/hi3670-hikey970.dts| 56 +- > arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 77 + > .../boot/dts/hisilicon/hikey970-drm.dtsi | 93 + > .../boot/dts/hisilicon/hikey970-pinctrl.dtsi | 548 +++- > .../boot/dts/hisilicon/hikey970-pmic.dtsi | 197 ++ > drivers/staging/hikey9xx/Kconfig |3 + > drivers/staging/hikey9xx/Makefile |1 + > drivers/staging/hikey9xx/gpu/Kconfig | 22 + > drivers/staging/hikey9xx/gpu/Makefile |9 + > drivers/staging/hikey9xx/gpu/kirin960_defs.c | 378 +++ > .../staging/hikey9xx/gpu/kirin960_dpe_reg.h | 233 ++ > drivers/staging/hikey9xx/gpu/kirin970_defs.c | 381 +++ > .../staging/hikey9xx/gpu/kirin970_dpe_reg.h | 1188 > drivers/staging/hikey9xx/gpu/kirin9xx_dpe.h | 2437 + > .../hikey9xx/gpu/kirin9xx_drm_dpe_utils.c | 1178 > .../hikey9xx/gpu/kirin9xx_drm_dpe_utils.h | 286 ++ > .../staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 368 +++ > .../staging/hikey9xx/gpu/kirin9xx_drm_drv.h | 57 + > .../staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 1063 +++ > .../hikey9xx/gpu/kirin9xx_drm_overlay_utils.c | 1005 +++ > .../hikey9xx/gpu/kirin9xx_dw_drm_dsi.c| 2132 ++ > .../hikey9xx/gpu/kirin9xx_dw_dsi_reg.h| 146 + > .../staging/hikey9xx/gpu/kirin9xx_fb_panel.h | 191 ++ > 25 files changed, 12229 insertions(+), 21 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/hisilicon,hi3660-dpe.yaml > create mode 100644 > Documentation/devicetree/bindings/display/hisilicon,hi3660-dsi.yaml Patch that intropduce new bindings must following the submitting patches guidelines for bindings. For once the subject is "dt-bindings: bla bla". Sam > create mode 100644 arch/arm64/boot/dts/hisilicon/hikey970-drm.dtsi > create mode 100644 arch/arm64/boot/dts/hisilicon/hikey970-pmic.dtsi > create mode 100644 drivers/staging/hikey9xx/gpu/Kconfig > create mode 100644 drivers/staging/hikey9xx/gpu/Makefile > create mode 100644 drivers/staging/hikey9xx/gpu/kirin960_defs.c > create mode 100644 drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h > create mode 100644 drivers/staging/hikey9xx/gpu/kirin970_defs.c > create mode 100644 drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_dpe.h > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_dw_dsi_reg.h > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_fb_panel.h > > -- > 2.26.2 > > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v14 0/2] Add initial support for slimport anx7625
Hi Xin Ji. On Thu, Jul 09, 2020 at 04:31:09PM +0800, Xin Ji wrote: > Hi all, > > The following series add support for the Slimport ANX7625 transmitter, a > ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable > device. > > > This is the v14 version, any mistakes, please let me know, I will fix it in > the next series. > > Change history: > v14: Fix comments from Sam and Nicolas > - Check flags at drm_bridge_attach > - Use panel_bridge instead of drm_panel > - Fix not correct return value Sorry for ignoring this for so long time. The patch applies but no longer builds. I could fix it locally but wanted to know if you have a later version to be applied? Sam > > v13: Fix comments from Launrent Pinchart and Rob Herring > - Picked up Rob's Reviewed-By > - Add .detect and .get_edid interface in bridge funcs. > > v12: Fix comments from Hsin-Yi Wang > - Rebase the code on kernel 5.7, fix DRM interface not match issue. > > v11: Fix comments from Rob Herring > - Update commit message. > - Remove unused label. > > v10: Fix comments from Rob Herring, Daniel. > - Fix dt_binding_check warning. > - Update description. > > v9: Fix comments from Sam, Nicolas, Daniel > - Remove extcon interface. > - Remove DPI support. > - Fix dt_binding_check complains. > - Code clean up and update description. > > v8: Fix comments from Nicolas. > - Fix several coding format. > - Update description. > > v7: > - Fix critical timing(eg:odd hfp/hbp) in "mode_fixup" interface, >enhance MIPI RX tolerance by setting register MIPI_DIGITAL_ADJ_1 to 0x3D. > > > Xin Ji (2): > dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema > drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP > > .../bindings/display/bridge/analogix,anx7625.yaml | 95 + > drivers/gpu/drm/bridge/analogix/Kconfig|9 + > drivers/gpu/drm/bridge/analogix/Makefile |1 + > drivers/gpu/drm/bridge/analogix/anx7625.c | 1939 > > drivers/gpu/drm/bridge/analogix/anx7625.h | 391 > 5 files changed, 2435 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h > > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v13 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP
Hi Xin.
On Tue, Jun 09, 2020 at 03:19:50PM +0800, Xin Ji wrote:
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
>
> Signed-off-by: Xin Ji
The bridge driver now implements the bridge functions for get_edid +
detect which is good.
But the bridge driver also needs to check the flags argument
of anx7625_bridge_attach() so the connector creation is optional.
This is required to prepare the bridge driver to fully support a
chain of bridges and is mandatory for new bridge drivers.
Futhermore the bridge driver needs to be converted to use the bridge
panel. See what other bridge drivers do.
In short - the drm_panel shall be replaced by a bridge in your
platform data structure.
Usual this end up in less code after the conversion.
Sam
> ---
> drivers/gpu/drm/bridge/analogix/Kconfig |9 +
> drivers/gpu/drm/bridge/analogix/Makefile |1 +
> drivers/gpu/drm/bridge/analogix/anx7625.c | 1999
> +
> drivers/gpu/drm/bridge/analogix/anx7625.h | 397 ++
> 4 files changed, 2406 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
> create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
>
> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
> b/drivers/gpu/drm/bridge/analogix/Kconfig
> index e1fa7d8..024ea2a 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -25,3 +25,12 @@ config DRM_ANALOGIX_ANX78XX
> config DRM_ANALOGIX_DP
> tristate
> depends on DRM
> +
> +config DRM_ANALOGIX_ANX7625
> + tristate "Analogix Anx7625 MIPI to DP interface support"
> + depends on DRM
> + depends on OF
> + help
> + ANX7625 is an ultra-low power 4K mobile HD transmitter
> + designed for portable devices. It converts MIPI/DPI to
> + DisplayPort1.3 4K.
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
> b/drivers/gpu/drm/bridge/analogix/Makefile
> index 97669b3..44da392 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0-only
> analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
> obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
> +obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
> obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> new file mode 100644
> index 000..db37f68
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -0,0 +1,1999 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright(c) 2020, Analogix Semiconductor. All rights reserved.
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "anx7625.h"
> +
> +/*
> + * There is a sync issue while access I2C register between AP(CPU) and
> + * internal firmware(OCM), to avoid the race condition, AP should access
> + * the reserved slave address before slave address occurs changes.
> + */
> +static int i2c_access_workaround(struct anx7625_data *ctx,
> + struct i2c_client *client)
> +{
> + u8 offset;
> + struct device *dev = >dev;
> + int ret;
> +
> + if (client == ctx->last_client)
> + return 0;
> +
> + ctx->last_client = client;
> +
> + if (client == ctx->i2c.tcpc_client)
> + offset = RSVD_00_ADDR;
> + else if (client == ctx->i2c.tx_p0_client)
> + offset = RSVD_D1_ADDR;
> + else if (client == ctx->i2c.tx_p1_client)
> + offset = RSVD_60_ADDR;
> + else if (client == ctx->i2c.rx_p0_client)
> + offset = RSVD_39_ADDR;
> + else if (client == ctx->i2c.rx_p1_client)
> + offset = RSVD_7F_ADDR;
> + else
> + offset = RSVD_00_ADDR;
> +
> + ret = i2c_smbus_write_byte_data(client, offset, 0x00);
> + if (ret < 0)
> + DRM_DEV_ERROR(dev,
> + "fail to access i2c id=%x\n:%x",
> + client->addr, offset);
> +
> + return ret;
> +}
Re: [PATCH] staging: fbtft: fb_st7789v: make HSD20_IPS numeric and not a string
Hi Colin/Greg.
On Thu, May 21, 2020 at 02:50:38PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Currently HSD20_IPS is defined as "true" and will always result in a
> non-zero result even if it is defined as "false" because it is an array
> and that will never be zero. Fix this by defining it as an integer 1
> rather than a literal string.
>
> Addessses-Coverity: ("Array compared against 0")
> Fixes: f03c9b788472 ("staging: fbtft: fb_st7789v: Initialize the Display")
> Signed-off-by: Colin Ian King
> ---
> drivers/staging/fbtft/fb_st7789v.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/fbtft/fb_st7789v.c
> b/drivers/staging/fbtft/fb_st7789v.c
> index ebc17e05ecd0..3a280cc1892c 100644
> --- a/drivers/staging/fbtft/fb_st7789v.c
> +++ b/drivers/staging/fbtft/fb_st7789v.c
> @@ -24,7 +24,7 @@
> "D0 05 0A 09 08 05 2E 44 45 0F 17 16 2B 33\n" \
> "D0 05 0A 09 08 05 2E 43 45 0F 16 16 2B 33"
>
> -#define HSD20_IPS "true"
> +#define HSD20_IPS 1
>
> /**
> * enum st7789v_command - ST7789V display controller commands
Patch does not apply to drm-misc-next, seems to be a staging thing.
So do not expext the DRM people to pick it up.
Sam
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
> > > + > > The way the internal panel - versus external connector is modelled > > looks like it could use some of the abstractions used by other bridge > > drivers. > > > > The connector_type shall for example for internal panels come > > form the panel. > > And use the panel bridge driver - see examples in patches I referenced > > before. > > > > And external connectors may beneft from using the > > display-connector bridge driver. > I'm not familiar with it, the extcon interface is Google engineer give > to me, I just follow their sample driver. If you think it is not good, > I'll remove the extcon support. It would be better to start without, and then add it later so we end up with a clean design. I for one would have an easier time reviewing. So please go ahead and remove it for now. Sam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
Hi Xin Ji On Mon, Apr 27, 2020 at 02:18:44PM +0800, Xin Ji wrote: > The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed > for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K. > > The ANX7625 can support both USB Type-C PD feature and MIPI DSI/DPI > to DP feature. This driver only enabled MIPI DSI/DPI to DP feature. You are sending this patch in an interesting time for bridge drivers. We are migrating to an approach where the individual brdge drivers exposes operations and where the connector creation is now optional. Laurent Pinchart is the architect behind it - and the required interfaces is well documented. You may find inspiration in a patchset I sent today: https://lore.kernel.org/dri-devel/20200427081850.17512-1-...@ravnborg.org/T/#t This is not reviewed - so keep an eye out for feedback. It would be great to base this on top of drm-misc-next, as this is where we will apply it eventually. As it is now it will not build due to internal API changes. The driver looks well structured with nice coding. I am missing an explanation why the current analogix infrastructure cannot be used. I have no clue but I just see other drivers in same dir that benefits from the infrastructure. So the questions seems relevant to be addressed. See a few more comments in the following, which you need to decide what to follow and what to ignore. I will make it obvious when something is a must to change, if I find anything such. Sorry for providing such massive feedback on v8. Please keep up the spirit and submit a v9 soon! Sam > > Signed-off-by: Xin Ji > --- > drivers/gpu/drm/bridge/Makefile |2 +- > drivers/gpu/drm/bridge/analogix/Kconfig |6 + > drivers/gpu/drm/bridge/analogix/Makefile |1 + > drivers/gpu/drm/bridge/analogix/anx7625.c | 2158 > + > drivers/gpu/drm/bridge/analogix/anx7625.h | 410 ++ > 5 files changed, 2576 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index 4934fcf..bcd388a 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -12,8 +12,8 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o > obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o > obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o > obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o > -obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o > +obj-y += analogix/ > obj-y += synopsys/ With this change we will always visit analogix/ which will trigger build of too much i think. Use: obj-$(CONFIG_ANALOGIX_ANX7625) += analogix/ like the other drivers do, if for nothing else then for consistency. > diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig > b/drivers/gpu/drm/bridge/analogix/Kconfig > index e930ff9..b2f127e 100644 > --- a/drivers/gpu/drm/bridge/analogix/Kconfig > +++ b/drivers/gpu/drm/bridge/analogix/Kconfig > @@ -2,3 +2,9 @@ > config DRM_ANALOGIX_DP > tristate > depends on DRM > + > +config ANALOGIX_ANX7625 > + tristate "Analogix MIPI to DP interface support" > + help > + ANX7625 is an ultra-low power 4K mobile HD transmitter designed > + for portable devices. It converts MIPI/DPI to DisplayPort1.3 4K. > diff --git a/drivers/gpu/drm/bridge/analogix/Makefile > b/drivers/gpu/drm/bridge/analogix/Makefile > index fdbf3fd..8a52867 100644 > --- a/drivers/gpu/drm/bridge/analogix/Makefile > +++ b/drivers/gpu/drm/bridge/analogix/Makefile > @@ -1,3 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0-only > +obj-$(CONFIG_ANALOGIX_ANX7625) += anx7625.o > analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o > obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c > b/drivers/gpu/drm/bridge/analogix/anx7625.c > new file mode 100644 > index 000..fff7a49 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c > @@ -0,0 +1,2158 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright(c) 2016, Analogix Semiconductor. All rights reserved. 2020? > + * > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +
Re: [PATCH v8 0/2] Add initial support for slimport anx7625
Hi Xin Ji On Mon, Apr 27, 2020 at 02:16:49PM +0800, Xin Ji wrote: > Hi all, > > The following series add support for the Slimport ANX7625 transmitter, a > ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable > device. > > This is the v8 version, any mistakes, please let me know, I will fix it in > the next series. This series fix several coding format and description. It would be great if you can add a summary of changes like this: v8: - fix several coding format - update description v7: - Bla bla I see no reason to dig out the old changelog, but start from now on. The cover letter (this mail) should give a general intro to the changes. The individual patches the detailed changelog. For each entry is is also a good practice to tell who gave the feedback that triggered the changes. There are many ways to handle this, take a look at a few submissions to dri-devel to be inspired. Sam > > Thanks, > Xin > > > > Xin Ji (2): > dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding > drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver > > .../bindings/display/bridge/anx7625.yaml | 91 + > drivers/gpu/drm/bridge/Makefile|2 +- > drivers/gpu/drm/bridge/analogix/Kconfig|6 + > drivers/gpu/drm/bridge/analogix/Makefile |1 + > drivers/gpu/drm/bridge/analogix/anx7625.c | 2158 > > drivers/gpu/drm/bridge/analogix/anx7625.h | 410 > 6 files changed, 2667 insertions(+), 1 deletion(-) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/anx7625.yaml > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h > > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
Hi Xin Ji
On Mon, Apr 27, 2020 at 02:17:46PM +0800, Xin Ji wrote:
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI to DisplayPort 1.3 4K.
Thanks for providing this binding.
When you re-submit please also send to devicet...@vger.kernel.org.
Running the binding through dt_binding_check gives me:
/home/sam/drm/linux.git/Documentation/devicetree/bindings/display/bridge/anx7625.yaml:
ignoring, error in schema:
warning: no schema found in file:
/home/sam/drm/linux.git/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
make[2]: ***
[/home/sam/drm/linux.git/Documentation/devicetree/bindings/Makefile:42:
Documentation/devicetree/bindings/processed-schema.yaml] Error 255
make[2]: *** Waiting for unfinished jobs
/home/sam/drm/linux.git/Documentation/devicetree/bindings/display/bridge/anx7625.yaml:
Additional properties are not allowed ('example' was unexpected)
/home/sam/drm/linux.git/Documentation/devicetree/bindings/display/bridge/anx7625.yaml:
Additional properties are not allowed ('example' was unexpected)
See writing-schemas.rst for instruction installing tools etc.
>
> You can add support to your board with binding.
>
> Example:
> anx7625_bridge: encoder@58 {
> compatible = "analogix,anx7625";
> reg = <0x58>;
> status = "okay";
> panel-flags = <1>;
> enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
> reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> reg = <0>;
> anx_1_in: endpoint {
> remote-endpoint = <_dsi>;
> };
> };
>
> port@2 {
> reg = <2>;
> anx_1_out: endpoint {
> remote-endpoint = <_in>;
> };
> };
> };
>
> Signed-off-by: Xin Ji
> ---
> .../bindings/display/bridge/anx7625.yaml | 91
> ++
> 1 file changed, 91 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/anx7625.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> new file mode 100644
> index 000..1149ebb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
Name the file "analogix,anx7625.yaml".
(We should rename anx6345.yaml, so others do not omit the company name)
> @@ -0,0 +1,91 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2019 Analogix Semiconductor, Inc.
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/bridge/anx7625.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
> +
> +maintainers:
> + - Xin Ji
> +
> +description: |
> + The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> + designed for portable devices.
> +
> +properties:
> + "#address-cells": true
> + "#size-cells": true
> +
> + compatible:
> +items:
> + - const: analogix,anx7625
> +
> + reg:
> +maxItems: 1
> +
> + panel-flags:
> +description: indicate the panel is internal or external.
> +maxItems: 1
This property hint at something needs to be modelled in a different way.
I do not recall other bindings need similar info.
> +
> + interrupts:
> +maxItems: 1
A description would be nice.
> +
> + enable-gpios:
> +description: used for power on chip control, POWER_EN pin D2.
> +maxItems: 1
> +
> + reset-gpios:
> +description: used for reset chip control, RESET_N pin B7.
> +maxItems: 1
> +
> + port@0:
> +type: object
> +description:
> + A port node pointing to MIPI DSI host port node.
> +
> + port@1:
> +type: object
> +description:
> + A port node pointing to MIPI DPI host port node.
Maybe explain how it differs from port@0 and why it is optional.
> +
> + port@2:
> +type: object
> +description:
> + A port node pointing to panel port node.
Unless there is a good reason not to then please use a ports node, like
you see in almost (all?) other bridge bindings.
> +
> +required:
> + - "#address-cells"
> + - "#size-cells"
> + - compatible
> + - reg
> + - port@0
> + - port@2
additionalProperties: false??
> +
> +example:
It must be named &qu
Re: [Outreachy kernel] [PATCH] staging: fbtft: Replace udelay with preferred usleep_range
On Sun, 2020-03-29 at 12:37 +0200, Julia Lawall wrote: > > On Sun, 29 Mar 2020, Soumyajit Deb wrote: > > > I had the same doubt the other day about the replacement of udelay() with > > usleep_range(). The corresponding range for the single argument value of > > udelay() is quite confusing as I couldn't decide the range. But as much as I > > noticed checkpatch.pl gives warning for replacing udelay() with > > usleep_range() by checking the argument value of udelay(). In the > > documentation, it is written udelay() should be used for a sleep time of at > > most 10 microseconds but between 10 microseconds and 20 milliseconds, > > usleep_range() should be used. > > I think the range is code specific and will depend on what range is > > acceptable and doesn't break the code. > > Please correct me if I am wrong. > > The range depends on the associated hardware. Just because checkpatch > suggests something doesn't mean that it is easy to address the problem. > > julia > Hi all, i think when it comes to a significant change in the code, we should at least be familiar with the driver or be able to test the change. In the very beginning of the Documentation/timers/timers-howto.rst there is the question: "Is my code in an atomic context?" It's not just about the range, it's more of at which context this code runs, for atomic-context -> udelay must be used. for non-atomic context -> usleep-range is better for power-management. unless we are familiar with the driver we wouldn't really know in what context this code is run at. This thread though had the same conversation about this change, for the same driver. https://patchwork.kernel.org/patch/11137125/ Sam > > > > More clarification on this issue will be helpful. > > > > On Sun, 29 Mar 2020, 15:17 Julia Lawall, wrote: > > > > > > On Sun, 29 Mar 2020, John Wyatt wrote: > > > > > On Sun, 2020-03-29 at 11:28 +0200, Julia Lawall wrote: > > > > > > > > On Sun, 29 Mar 2020, John B. Wyatt IV wrote: > > > > > > > > > Fix style issue with usleep_range being reported as > > preferred over > > > > > udelay. > > > > > > > > > > Issue reported by checkpatch. > > > > > > > > > > Please review. > > > > > > > > > > As written in Documentation/timers/timers-howto.rst udelay > > is the > > > > > generally preferred API. hrtimers, as noted in the docs, > > may be too > > > > > expensive for this short timer. > > > > > > > > > > Are the docs out of date, or, is this a checkpatch issue? > > > > > > > > > > Signed-off-by: John B. Wyatt IV > > > > > --- > > > > > drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c > > > > > b/drivers/staging/fbtft/fb_agm1264k-fl.c > > > > > index ec97ad27..019c8cce6bab 100644 > > > > > --- a/drivers/staging/fbtft/fb_agm1264k-fl.c > > > > > +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c > > > > > @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par) > > > > > dev_dbg(par->info->device, "%s()\n", __func__); > > > > > > > > > > gpiod_set_value(par->gpio.reset, 0); > > > > > - udelay(20); > > > > > + usleep_range(20, 20); > > > > > > > > usleep_range should have a range, eg usleep_range(50, > > 100);. But it > > > > is > > > > hard to know a priori what the range should be. So it is > > probably > > > > better > > > > to leave the code alone. > > > > > > Understood. > > > > > > With the question I wrote in the commit message: > > > > > > "As written in Documentation/timers/timers-howto.rst udelay is > > the > > > generally preferred API. hrtimers, as noted in the docs, may > > be too > > > expensive for this short timer. > > > > > > Are the docs out of date, or, is this a checkpatch issue?" > >
Re: fbtft: 5 years in staging
Hi Noralf On Sun, Feb 02, 2020 at 04:41:54PM +0100, Noralf Trønnes wrote: > Hi, > > Since I'm the original author of fbtft I thought I'd highlight a couple > of issues that's probably not well known. > > Right after fbtft was added, fbdev was closed for new drivers[1] and > the fbdev maintainer wanted to remove fbtft as a consequence of that > decision, but Greg KH said he'd keep fbtft drivers in staging > "until a matching DRM driver is present in the tree"[2]. > > There are 2 issues wrt the goal of making a matching DRM driver > (strictly speaking). One is impossible to do (policy), the other is > unlikely to happen: > > 1. Device Tree 'init' property > > All fbtft drivers have controller setup code that matches one > particular display panel. From the start of fbtft it was possible to > override this using platform data. Later when Device Tree support was > added, an 'init=' property to do the same was added. > > Example: > init = <0x1e5 0x78F0 > 0x101 0x0100 > 0x232 > 0x107 0x0133>; > > This translates to: > register_write(0x00e5, 0x78F0); > register_write(0x0001, 0x0100); > mdelay(32); > register_write(0x0007, 0x0133); > > AFAIU setting register values from DT is a no-go, so this functionality > can't be replicated in a DRM driver. Many displays are made to work > using this mechanism, in particular ili9341 based ones. > > 2. Parallel bus interface > > All fbtft drivers support both a SPI and a parallel bus interface > through the fbtft helper module. Many (not all) controllers support more > than one interface. The parallel bus support was added to fbtft in its > early days when not many SPI displays were available (nowadays there's > lots to choose from). fbtft uses bitbanging to drive the parallel > interface so it's really slow, even more slow than SPI and SPI with DMA > beats it thoroughly. I know there are people that use the paralell bus > support, but I don't see much point in it unless we get a parallel bus > subsystem that can use the dedicated hw on certain SoC's (Beaglebone, > Pi). And those SOC's most likely have a parallel video/RGB bus as well, > which IMO is a much better option for a panel. > > > The following drivers have DRM counterparts that have the same panel > setup code: > > - fb_hx8357d.c: drivers/gpu/drm/tiny/hx8357d.c > - fb_ili9341.c: drivers/gpu/drm/tiny/mi0283qt.c > - fb_st7735r.c: drivers/gpu/drm/tiny/st7735r.c > - fb_ili9486.c: Patches are posted on dri-devel[3] > > But they don't support all panels based on that controller and they > don't have parallel bus support. > > There is actually also another obstacle for conversion and that is, some > of the displays (for which there is builtin driver support) might be > impossible to source except as second hand. And it's not always obvious > which panel is supported by a certain driver. > At least the displays supported by these drivers are listed as > discontinued on the fbtft wiki[4]: > - fb_hx8340bn.c > - fb_hx8347d.c > - fb_ili9320 > > This one never made it from a prototype to an actual product, because > it was too slow: > - fb_watterott.c > > I have no plans to convert fbtft drivers myself, but I figured a 5 year > anniversary was a good excuse for a status update. Thanks for the history lesson and the status update, a very informative and interesting read. Thanks for all your work in this area! Sam > > Noralf. > > [1] https://lkml.org/lkml/2015/9/24/253 > [2] https://lkml.org/lkml/2016/11/23/146 > [3] https://patchwork.freedesktop.org/series/72645/ > [4] https://github.com/notro/fbtft/wiki/LCD-Modules#discontinued-products > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
partnership!!
My Message Good day, I´m Sam from Hong Kong. I have a business & private offer from the top executive to seek your partnership in re-profiling some offshore funds for investment purpose in your country Reply back to my email samtsi...@yandex.com for more detail's. Regards, Sam Email: samtsi...@yandex.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] FBTFT: fbtft-bus: Fix code style problems
Hi Dante. > Hello Sam, thank you very much for your comments, > As I told Dan (my email did not reach the mailing list) this is my > first attempt to contribute, > So I'm learning a lot from your advice and corrections. > > I will look for TODO lists to see if there are more useful > contributions to make, all suggestions are also welcome. Keep the good spirit, and find some other driver to look into. You must realise than experienced developers sometimes goes through several version before a patch is ready. So expect it to be a bumpy ride the first few times. Good luck! Sam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] FBTFT: fbtft-bus: Fix code style problems
Hi Eze
>
> Why is this driver still here? I thought we migrated everyhing to
> tinydrm already.
Some have been ported, some are waiting for a user to do the port.
If you looks at tinydrm you will see:
ili9225.c ili9341.c
And we also have under panel:
panel-ilitek-ili9881c.c
panel-ilitek-ili9322.c
But in staging there are more panels than just these.
So we have not yet ported all.
And there is today no list of what is missing.
Sam
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] FBTFT: fbtft-bus: Fix code style problems
Hi Dante Thanks for the patch. On Sat, Mar 09, 2019 at 06:48:52PM -0300, Dante Paz wrote: > From: Dante Paz > > Style and coding function issues were corrected, by avoiding macro > functions with a conflicting coding style. > Signed-off-by: Dante Paz But it raised a few comments. The staging/fbtft is a dumping of a set of drivers that in the end will be migrated to DRM. And there is not much gained trying to do coding style changes to these drivers. So please conmsider finding a drver where this is more relevant. Furthermore that patch presented is hard to review as it contains too much changes in one go. As a rule of thumb include only one type of change per patch. This is worth to keep in mind for future submissions. It it then also good to present the trivial changes first(*), and the less trivial changes later. (*) Like whitespace to tabs, spellign errors etc. Sam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drm/vboxvideo: Move vboxvideo driver out of staging
Hi Hans.
Just a bunch of random observations that I hope you find use of.
Sam
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index cb88528e7b10..6b4d6c957da8 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -315,6 +315,8 @@ source "drivers/gpu/drm/tve200/Kconfig"
>
> source "drivers/gpu/drm/xen/Kconfig"
>
> +source "drivers/gpu/drm/vboxvideo/Kconfig"
> +
> # Keep legacy drivers last
>
> menuconfig DRM_LEGACY
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index a6771cef85e2..133606802300 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -107,3 +107,4 @@ obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
> obj-$(CONFIG_DRM_PL111) += pl111/
> obj-$(CONFIG_DRM_TVE200) += tve200/
> obj-$(CONFIG_DRM_XEN) += xen/
> +obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/
Is it the most logical place to add this in the end?
You are asking for merge problems if you do so, but then
the drm drivers does not seem to follow any good order
so this may be fine.
> +++ b/drivers/gpu/drm/vboxvideo/Makefile
> @@ -0,0 +1,8 @@
> +# SPDX-License-Identifier: GPL-2.0
> +ccflags-y := -Iinclude/drm
This should not be required.
If required then fix the offending #include
> +
> +vboxvideo-y := hgsmi_base.o modesetting.o vbva_base.o \
> + vbox_drv.o vbox_fb.o vbox_hgsmi.o vbox_irq.o vbox_main.o \
> + vbox_mode.o vbox_prime.o vbox_ttm.o
> +
> +obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo.o
> diff --git a/drivers/gpu/drm/vboxvideo/hgsmi_base.c
> b/drivers/gpu/drm/vboxvideo/hgsmi_base.c
> new file mode 100644
> index ..361d3193258e
> --- /dev/null
> +++ b/drivers/gpu/drm/vboxvideo/hgsmi_base.c
> @@ -0,0 +1,207 @@
> +// SPDX-License-Identifier: MIT
> +/* Copyright (C) 2006-2017 Oracle Corporation */
2018?
General comment for all files.
> + union {
> + /* Opaque placeholder to make the union 8 bytes. */
> + u8 header_data[8];
Further down you have 2 x u32, so the union is guaranteed to be 64 bits.
So header_data is redundant.
> +
> + /* HGSMI_BUFFER_HEADER_F_SEQ_SINGLE */
> + struct {
> + u32 reserved1; /* A reserved field, initialize to 0. */
> + u32 reserved2; /* A reserved field, initialize to 0. */
> + } buffer;
> --- /dev/null
> +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> @@ -0,0 +1,280 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright (C) 2013-2017 Oracle Corporation
> + * This file is based on ast_drv.c
> + * Copyright 2012 Red Hat Inc.
> + * Authors: Dave Airlie
> + * Michael Thayer + * Hans de Goede
> + */
> +#include
> +#include
> +#include
> +
> +#include
We are trying to get rid of drmP - replace with more specific includes.
Goes for all uses of drmP.h
> +
> +static int vbox_modeset = -1;
> +
> +MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
> +module_param_named(modeset, vbox_modeset, int, 0400);
> +
> +static struct drm_driver driver;
> +
> +static const struct pci_device_id pciidlist[] = {
> + { 0x80ee, 0xbeef, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> + { 0, 0, 0},
> +};
Use PCI_DEVICE()?
> +static int vbox_pci_probe(struct pci_dev *pdev, const struct pci_device_id
> *ent)
> +{
> + struct vbox_private *vbox;
> + int ret = 0;
> +
> + if (!vbox_check_supported(VBE_DISPI_ID_HGSMI))
> + return -ENODEV;
> +
> + vbox = kzalloc(sizeof(*vbox), GFP_KERNEL);
> + if (!vbox)
> + return -ENOMEM;
> +
> + ret = drm_dev_init(>ddev, , >dev);
> + if (ret) {
> + kfree(vbox);
> + return ret;
> + }
> +
> + vbox->ddev.pdev = pdev;
> + vbox->ddev.dev_private = vbox;
> + pci_set_drvdata(pdev, vbox);
> + mutex_init(>hw_mutex);
> +
> + ret = pci_enable_device(pdev);
> + if (ret)
> + goto err_dev_put;
> +
> + ret = vbox_hw_init(vbox);
> + if (ret)
> + goto err_pci_disable;
> +
> + ret = vbox_mm_init(vbox);
> + if (ret)
> + goto err_hw_fini;
> +
> + ret = vbox_mode_init(vbox);
> + if (ret)
> + goto err_mm_fini;
> +
> + ret = vbox_irq_init(vbox);
> + if (ret)
> + goto err_mode_fini;
> +
> + ret = drm_fb_helper_fbdev_setup(>ddev, >fb_helper,
> + _fb_helper_funcs, 32,
> + vbox->num_crtcs);
> + if (ret)
> + goto err_irq_fini;
> +
> +
Re: [PATCH 00/25] Change tty_port(standard)_install's return type
Hi Jaejoong.
> Change return type for tty functions. Patch No.01
> tty: Change return type to void
Adding this patch first will generate a lot of warnings
until all users are updated.
It is usual practice to prepare all users
and then apply the infrastructure changes as the
last patch.
Then people will not see a lot of warnings when
they build something in the middle,
and I guess current stack set may also generate
a few mails from the 0-day build infrastructure.
> isdn: i4l: isdn_tty: Change return type to void
And a nitpick on the patch description.
This patch do not change any return type, but
it ignore the return value og tty_part_install().
Same goes for all ramaining patches.
Sam
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
follow up
Want to know if you have photos for editing? We can edit 300+ images each day. We can work on ecommerce photos, jewelry photos, and portrait photos. We give cut out and clipping path for different kind of photos, and also we provide retouching for them. Send us a test photo and we will do testing for you. Thanks, Sam Dennis ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
and for the photos
Want to know if you have photos for editing? We can edit 300+ images each day. We can work on ecommerce photos, jewelry photos, and portrait photos. We give cut out and clipping path for different kind of photos, and also we provide retouching for them. Send us a test photo and we will do testing for you. Thanks, Sam Dennis ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
we look after your photos
Do you have photos for editing? We are image team and we can process 500+ images each day. We edit ecommerce photo, jewelry photos, and beauty model photos. also wedding photos. We do cut out and clipping path for photos, also retouching. You may send us a test photo to check our quality. Thanks, Sam Parker ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
your images need editing and
We have been hailed as one of the top-tier photo retouching service providers in the world, supplying its tremendous expertise to more than 20 nations, and catering to myriad industry needs that include E-Commerce, Photography, and stock photo. Handling high volumes maintaining the highest standards within the deadlines is our motto, thus far we are successfully processing close to 100,000 images a month. We assure you the quality in the retouching services. What we do: Clipping path; Deep etch process Image masking Remove background Portrait retouching Jewelry photo retouching Fashion photo retouching We can provide you editing test on your photos. Please reply if you are interested. Thanks, Sam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: dgnc: Add whitespace around OR'd flags ("|")
This patch fixes the checkpatch.pl message: CHECK: spaces preferred around that '|' (ctx:VxV) + writeb((UART_FCR_ENABLE_FIFO|UART_FCR_CLEAR_RCVR|UART_FCR_CLEAR_XMIT), ^ ^ As per the guidelines for coding style in the kernel, I have updated the digi international driver to include spaces around the OR'd flags; not only is this formatting issue caught by `checkpatch.pl`, in the next `if` block the correct formatting is used, leading to both incorrect and inconsistent code formatting. This patch puts the line in question at 82 characters---while this is over the recommended limit, there are no clear locations to break the line and it barely breaks the cutoff. Signed-off-by: Sam Horlbeck Olsen <sam.horl...@gmail.com> --- drivers/staging/dgnc/dgnc_cls.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/dgnc/dgnc_cls.c b/drivers/staging/dgnc/dgnc_cls.c index 0ff3139..5e46ac8 100644 --- a/drivers/staging/dgnc/dgnc_cls.c +++ b/drivers/staging/dgnc/dgnc_cls.c @@ -1168,7 +1168,7 @@ static void cls_uart_init(struct channel_t *ch) /* Clear out UART and FIFO */ readb(>ch_cls_uart->txrx); - writeb((UART_FCR_ENABLE_FIFO|UART_FCR_CLEAR_RCVR|UART_FCR_CLEAR_XMIT), + writeb((UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT), >ch_cls_uart->isr_fcr); udelay(10); -- 2.5.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: line6: fix parentheses around macro in usbdefs.h
This patch fixes the error Macros with complex values should be enclosed in
parentheses, as reported by checkpatch.pl.
Signed-off-by: Sam van Kampen s...@tehsvk.net
---
drivers/staging/line6/usbdefs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/line6/usbdefs.h b/drivers/staging/line6/usbdefs.h
index 2d1cc47..48958b5 100644
--- a/drivers/staging/line6/usbdefs.h
+++ b/drivers/staging/line6/usbdefs.h
@@ -40,7 +40,7 @@
#define LINE6_DEVID_TONEPORT_UX2 0x4142
#define LINE6_DEVID_VARIAX0x534d
-#define LINE6_BIT(x) LINE6_BIT_ ## x = 1 LINE6_INDEX_ ## x
+#define LINE6_BIT(x) (LINE6_BIT_ ## x = 1 LINE6_INDEX_ ## x)
enum {
LINE6_INDEX_BASSPODXT,
--
2.0.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] Staging: comedi: amplc_pc236: a blank line inserted
A 'Missing a blank line after declarations' warning fixed by inserting
a blank line after struct pointer declaration.
Signed-off-by: Sam Asadi asadi.sam...@gmail.com
---
drivers/staging/comedi/drivers/amplc_pc236.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/comedi/drivers/amplc_pc236.c
b/drivers/staging/comedi/drivers/amplc_pc236.c
index c9a96ad..d0f81f8 100644
--- a/drivers/staging/comedi/drivers/amplc_pc236.c
+++ b/drivers/staging/comedi/drivers/amplc_pc236.c
@@ -515,6 +515,7 @@ static void pc236_detach(struct comedi_device *dev)
comedi_legacy_detach(dev);
} else if (is_pci_board(thisboard)) {
struct pci_dev *pcidev = comedi_to_pci_dev(dev);
+
if (dev-irq)
free_irq(dev-irq, dev);
comedi_pci_disable(dev);
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] Staging: comedi: amcc_s5933: a style issue fixed
A 'line over 80 characters' fixed by removing comment to the previous line. Signed-off-by: Sam Asadi asadi.sam...@gmail.com --- drivers/staging/comedi/drivers/amcc_s5933.h |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/comedi/drivers/amcc_s5933.h b/drivers/staging/comedi/drivers/amcc_s5933.h index 089b71f..c9f2afa 100644 --- a/drivers/staging/comedi/drivers/amcc_s5933.h +++ b/drivers/staging/comedi/drivers/amcc_s5933.h @@ -54,7 +54,8 @@ #define INTCSR_INBOX_FULL_INT 0x1000 /* enable inbox full interrupt */ /* read, or write clear inbox full interrupt */ #define INTCSR_INBOX_INTR_STATUS 0x2 -#define INTCSR_INTR_ASSERTED 0x80/* read only, interrupt asserted */ +/* read only, interrupt asserted */ +#define INTCSR_INTR_ASSERTED 0x80 // /* AMCC - PCI non-volatile ram command register (byte 3 of master control/status register) */ -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] Staging: comedi: amcc_s5933: a line over 80 fixed
A 'line over 80 characters' fixed by removing comment to previous line. Signed-off-by: Sam Asadi asadi.sam...@gmail.com --- drivers/staging/comedi/drivers/amcc_s5933.h |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/comedi/drivers/amcc_s5933.h b/drivers/staging/comedi/drivers/amcc_s5933.h index 2ba7364..089b71f 100644 --- a/drivers/staging/comedi/drivers/amcc_s5933.h +++ b/drivers/staging/comedi/drivers/amcc_s5933.h @@ -52,7 +52,8 @@ #define INTCSR_INBOX_BYTE(x) (((x) 0x3) 8) #define INTCSR_INBOX_SELECT(x) (((x) 0x3) 10) #define INTCSR_INBOX_FULL_INT 0x1000 /* enable inbox full interrupt */ -#define INTCSR_INBOX_INTR_STATUS 0x2 /* read, or write clear inbox full interrupt */ +/* read, or write clear inbox full interrupt */ +#define INTCSR_INBOX_INTR_STATUS 0x2 #define INTCSR_INTR_ASSERTED 0x80/* read only, interrupt asserted */ // -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] Staging: comedi: adl_paci9118: organized entry comments
Introductory comments organized according to Linux's comment coding style. Signed-off-by: Sam Asadi asadi.sam...@gmail.com --- drivers/staging/comedi/drivers/adl_pci9118.c | 109 +- 1 file changed, 55 insertions(+), 54 deletions(-) diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c b/drivers/staging/comedi/drivers/adl_pci9118.c index a715cd3..f916632 100644 --- a/drivers/staging/comedi/drivers/adl_pci9118.c +++ b/drivers/staging/comedi/drivers/adl_pci9118.c @@ -7,61 +7,62 @@ * * Author: Michal Dobes do...@tesnet.cz * -*/ + */ + /* -Driver: adl_pci9118 -Description: Adlink PCI-9118DG, PCI-9118HG, PCI-9118HR -Author: Michal Dobes do...@tesnet.cz -Devices: [ADLink] PCI-9118DG (pci9118dg), PCI-9118HG (pci9118hg), - PCI-9118HR (pci9118hr) -Status: works - -This driver supports AI, AO, DI and DO subdevices. -AI subdevice supports cmd and insn interface, -other subdevices support only insn interface. -For AI: -- If cmd-scan_begin_src=TRIG_EXT then trigger input is TGIN (pin 46). -- If cmd-convert_src=TRIG_EXT then trigger input is EXTTRG (pin 44). -- If cmd-start_src/stop_src=TRIG_EXT then trigger input is TGIN (pin 46). -- It is not necessary to have cmd.scan_end_arg=cmd.chanlist_len but - cmd.scan_end_arg modulo cmd.chanlist_len must by 0. -- If return value of cmdtest is 5 then you've bad channel list - (it isn't possible mixture S.E. and DIFF inputs or bipolar and unipolar - ranges). - -There are some hardware limitations: -a) You cann't use mixture of unipolar/bipoar ranges or differencial/single - ended inputs. -b) DMA transfers must have the length aligned to two samples (32 bit), - so there is some problems if cmd-chanlist_len is odd. This driver tries - bypass this with adding one sample to the end of the every scan and discard - it on output but this cann't be used if cmd-scan_begin_src=TRIG_FOLLOW - and is used flag TRIG_WAKE_EOS, then driver switch to interrupt driven mode - with interrupt after every sample. -c) If isn't used DMA then you can use only mode where - cmd-scan_begin_src=TRIG_FOLLOW. - -Configuration options: - [0] - PCI bus of device (optional) - [1] - PCI slot of device (optional) - If bus/slot is not specified, then first available PCI - card will be used. - [2] - 0= standard 8 DIFF/16 SE channels configuration - n = external multiplexer connected, 1 = n = 256 - [3] - 0=autoselect DMA or EOC interrupts operation - 1 = disable DMA mode - 3 = disable DMA and INT, only insn interface will work - [4] - samplehold signal - card can generate signal for external SH board - 0 = use SSHO(pin 45) signal is generated in onboard hardware SH logic - 0 != use ADCHN7(pin 23) signal is generated from driver, number say how - long delay is requested in ns and sign polarity of the hold - (in this case external multiplexor can serve only 128 channels) - [5] - 0=stop measure on all hardware errors - 2 | = ignore ADOR - A/D Overrun status - 8|=ignore Bover - A/D Burst Mode Overrun status - 256|=ignore nFull - A/D FIFO Full status - -*/ + * Driver: adl_pci9118 + * Description: Adlink PCI-9118DG, PCI-9118HG, PCI-9118HR + * Author: Michal Dobes do...@tesnet.cz + * Devices: [ADLink] PCI-9118DG (pci9118dg), PCI-9118HG (pci9118hg), + * PCI-9118HR (pci9118hr) + * Status: works + * + * This driver supports AI, AO, DI and DO subdevices. + * AI subdevice supports cmd and insn interface, + * other subdevices support only insn interface. + * For AI: + * - If cmd-scan_begin_src=TRIG_EXT then trigger input is TGIN (pin 46). + * - If cmd-convert_src=TRIG_EXT then trigger input is EXTTRG (pin 44). + * - If cmd-start_src/stop_src=TRIG_EXT then trigger input is TGIN (pin 46). + * - It is not necessary to have cmd.scan_end_arg=cmd.chanlist_len but + * cmd.scan_end_arg modulo cmd.chanlist_len must by 0. + * - If return value of cmdtest is 5 then you've bad channel list + * (it isn't possible mixture S.E. and DIFF inputs or bipolar and unipolar + * ranges). + * + * There are some hardware limitations: + * a) You cann't use mixture of unipolar/bipoar ranges or differencial/single + * ended inputs. + * b) DMA transfers must have the length aligned to two samples (32 bit), + * so there is some problems if cmd-chanlist_len is odd. This driver tries + * bypass this with adding one sample to the end of the every scan and discard + * it on output but this cann't be used if cmd-scan_begin_src=TRIG_FOLLOW + * and is used flag TRIG_WAKE_EOS, then driver switch to interrupt driven mode + * with interrupt after every sample. + * c) If isn't used DMA then you can use only mode where + * cmd-scan_begin_src=TRIG_FOLLOW. + * + * Configuration options: + * [0] - PCI bus of device (optional) + * [1] - PCI slot of device (optional) + * If bus/slot is not specified, then first available PCI + * card will be used. + * [2] - 0= standard 8 DIFF/16 SE channels configuration
[PATCH 2/2] Staging: comedi: adv_pci1710.c line over 80 fixed
A line over 80 issue fixed, which is a comment. Signed-off-by: Sam Asadi asadi.sam...@gmail.com --- drivers/staging/comedi/drivers/adv_pci1710.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/comedi/drivers/adv_pci1710.c b/drivers/staging/comedi/drivers/adv_pci1710.c index 602b7a1..13ff78c 100644 --- a/drivers/staging/comedi/drivers/adv_pci1710.c +++ b/drivers/staging/comedi/drivers/adv_pci1710.c @@ -723,7 +723,8 @@ static int pci171x_ai_cancel(struct comedi_device *dev, devpriv-CntrlReg = Control_CNT0; devpriv-CntrlReg |= Control_SW; - outw(devpriv-CntrlReg, dev-iobase + PCI171x_CONTROL); /* reset any operations */ + outw(devpriv-CntrlReg, dev-iobase + PCI171x_CONTROL); + /* reset any operations */ pci171x_start_pacer(dev, false); outb(0, dev-iobase + PCI171x_CLRFIFO); outb(0, dev-iobase + PCI171x_CLRINT); -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] Staging: comedi: adv_pci1710: a line over 80 fixed
a line over 80 issue fixed by removing the cross-lined comment to the previous line. Signed-off-by: Sam Asadi asadi.sam...@gmail.com --- drivers/staging/comedi/drivers/adv_pci1710.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/comedi/drivers/adv_pci1710.c b/drivers/staging/comedi/drivers/adv_pci1710.c index 602b7a1..040a5cb 100644 --- a/drivers/staging/comedi/drivers/adv_pci1710.c +++ b/drivers/staging/comedi/drivers/adv_pci1710.c @@ -722,8 +722,9 @@ static int pci171x_ai_cancel(struct comedi_device *dev, default: devpriv-CntrlReg = Control_CNT0; devpriv-CntrlReg |= Control_SW; - - outw(devpriv-CntrlReg, dev-iobase + PCI171x_CONTROL); /* reset any operations */ + + /* reset any operations */ + outw(devpriv-CntrlReg, dev-iobase + PCI171x_CONTROL); pci171x_start_pacer(dev, false); outb(0, dev-iobase + PCI171x_CLRFIFO); outb(0, dev-iobase + PCI171x_CLRINT); -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] Staging: comedi: adl_pci9118: commenting style issue fixed
A 'quoted string split across lines' issue fixed, while a better use of
language applied to the comment.
Signed-off-by: Sam Asadi asadi.sam...@gmail.com
---
drivers/staging/comedi/drivers/adl_pci9118.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c
b/drivers/staging/comedi/drivers/adl_pci9118.c
index 93bd9ee..7365f31 100644
--- a/drivers/staging/comedi/drivers/adl_pci9118.c
+++ b/drivers/staging/comedi/drivers/adl_pci9118.c
@@ -418,8 +418,7 @@ static int check_channel_list(struct comedi_device *dev,
if ((CR_RANGE(chanlist[i]) PCI9118_BIPOLAR_RANGES) !=
(bipolar)) {
comedi_error(dev,
-Bipolar and unipolar ranges
- can't be mixtured!);
+Bipolar and unipolar ranges can't
be mixed!);
return 0;
}
if (!devpriv-usemux differencial
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] Staging: comedi: adl_pci9118: line over 80 fixed
A 'line over 80 characters' issue fixed.
Signed-off-by: Sam Asadi asadi.sam...@gmail.com
---
drivers/staging/comedi/drivers/adl_pci9118.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c
b/drivers/staging/comedi/drivers/adl_pci9118.c
index 7365f31..a715cd3 100644
--- a/drivers/staging/comedi/drivers/adl_pci9118.c
+++ b/drivers/staging/comedi/drivers/adl_pci9118.c
@@ -346,7 +346,7 @@ struct pci9118_private {
* on external start
*/
unsigned short ao_data[2]; /* data output buffer */
- char dma_doublebuf; /* we can use double buffering
*/
+ char dma_doublebuf; /* use double buffering */
unsigned int dma_actbuf;/* which buffer is used now */
unsigned short *dmabuf_virt[2]; /*
* pointers to begin of
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: comedi: adl_pci9118: a style issue fixed
'quoted string split across lines' warning in checkpatching fixed
by group whole string in one line.
Signed-off-by: Sam Asadi asadi.sam...@gmail.com
---
drivers/staging/comedi/drivers/adl_pci9118.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c
b/drivers/staging/comedi/drivers/adl_pci9118.c
index 59a65cb..b2d25f5 100644
--- a/drivers/staging/comedi/drivers/adl_pci9118.c
+++ b/drivers/staging/comedi/drivers/adl_pci9118.c
@@ -412,8 +412,7 @@ static int check_channel_list(struct comedi_device *dev,
if ((CR_AREF(chanlist[i]) == AREF_DIFF) !=
(differencial)) {
comedi_error(dev,
-Differencial and single ended
- inputs can't be mixtured!);
+Differencial and single ended
inputs can't be mixtured!);
return 0;
}
if ((CR_RANGE(chanlist[i]) PCI9118_BIPOLAR_RANGES) !=
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] Staging: comedi: adl_pci9118: a style issue fixed
'quoted string split across lines' warning in checkpatching fixed
by group whole string in one line.
Signed-off-by: Sam Asadi asadi.sam...@gmail.com
---
drivers/staging/comedi/drivers/adl_pci9118.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c
b/drivers/staging/comedi/drivers/adl_pci9118.c
index 59a65cb..b2d25f5 100644
--- a/drivers/staging/comedi/drivers/adl_pci9118.c
+++ b/drivers/staging/comedi/drivers/adl_pci9118.c
@@ -412,8 +412,7 @@ static int check_channel_list(struct comedi_device *dev,
if ((CR_AREF(chanlist[i]) == AREF_DIFF) !=
(differencial)) {
comedi_error(dev,
-Differencial and single ended
- inputs can't be mixtured!);
+Differencial and single ended
inputs can't be mixtured!);
return 0;
}
if ((CR_RANGE(chanlist[i]) PCI9118_BIPOLAR_RANGES) !=
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/2] Staging: Comedi: adl_pci9118: 2 style issues fixed
2 style issues fixed: one misspelling a quoted string split across lines. Sam Asadi (2): Staging: comedi: adl_pci9118: a style issue fixed Staging: comedi: adl_pci9118: fractured spelling fixed drivers/staging/comedi/drivers/adl_pci9118.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] Staging: comedi: adl_pci9118: fractured spelling fixed
a fractured spelling in previous style issue fix mended.
Signed-off-by: Sam Asadi asadi.sam...@gmail.com
---
drivers/staging/comedi/drivers/adl_pci9118.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c
b/drivers/staging/comedi/drivers/adl_pci9118.c
index b2d25f5..f2a2d04 100644
--- a/drivers/staging/comedi/drivers/adl_pci9118.c
+++ b/drivers/staging/comedi/drivers/adl_pci9118.c
@@ -412,7 +412,7 @@ static int check_channel_list(struct comedi_device *dev,
if ((CR_AREF(chanlist[i]) == AREF_DIFF) !=
(differencial)) {
comedi_error(dev,
-Differencial and single ended
inputs can't be mixtured!);
+Differential and single ended
inputs can't be mixtured!);
return 0;
}
if ((CR_RANGE(chanlist[i]) PCI9118_BIPOLAR_RANGES) !=
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/3] Staging: adl_pci9118: a language issue fixed
For better use of English, 'mixtured' which is not right, replaced
by 'mixed'.
Signed-off-by: Sam Asadi asadi.sam...@gmail.com
---
drivers/staging/comedi/drivers/adl_pci9118.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c
b/drivers/staging/comedi/drivers/adl_pci9118.c
index f2a2d04..93bd9ee 100644
--- a/drivers/staging/comedi/drivers/adl_pci9118.c
+++ b/drivers/staging/comedi/drivers/adl_pci9118.c
@@ -412,7 +412,7 @@ static int check_channel_list(struct comedi_device *dev,
if ((CR_AREF(chanlist[i]) == AREF_DIFF) !=
(differencial)) {
comedi_error(dev,
-Differential and single ended
inputs can't be mixtured!);
+Differential and single ended
inputs can't be mixed!);
return 0;
}
if ((CR_RANGE(chanlist[i]) PCI9118_BIPOLAR_RANGES) !=
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] Staging: adl_pci9118: a style issue fixed
a 'quoted string split across lines' fixed while better use of
English applied to the text.
Signed-off-by: Sam Asadi asadi.sam...@gmail.com
---
drivers/staging/comedi/drivers/adl_pci9118.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c
b/drivers/staging/comedi/drivers/adl_pci9118.c
index 93bd9ee..7365f31 100644
--- a/drivers/staging/comedi/drivers/adl_pci9118.c
+++ b/drivers/staging/comedi/drivers/adl_pci9118.c
@@ -418,8 +418,7 @@ static int check_channel_list(struct comedi_device *dev,
if ((CR_RANGE(chanlist[i]) PCI9118_BIPOLAR_RANGES) !=
(bipolar)) {
comedi_error(dev,
-Bipolar and unipolar ranges
- can't be mixtured!);
+Bipolar and unipolar ranges can't
be mixed!);
return 0;
}
if (!devpriv-usemux differencial
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 94/94] Staging: comedi: 3 files revised fixed style issues
From: Sam Asadi asadi.sam...@gmail.com
3 files in 'staging/comedi/drivers/' revised again
and style issues fixed
Signed-off-by: Sam Asadi asadi.sam...@gmail.com
modified: drivers/staging/comedi/drivers/8253.h
modified: drivers/staging/comedi/drivers/8255.c
modified: drivers/staging/comedi/drivers/adl_pci9118.c
---
drivers/staging/comedi/drivers/8253.h| 34 +++---
drivers/staging/comedi/drivers/8255.c| 154 +-
drivers/staging/comedi/drivers/adl_pci9118.c | 140 +++
3 files changed, 167 insertions(+), 161 deletions(-)
diff --git a/drivers/staging/comedi/drivers/8253.h
b/drivers/staging/comedi/drivers/8253.h
index f6b8607..31d0fc9 100644
--- a/drivers/staging/comedi/drivers/8253.h
+++ b/drivers/staging/comedi/drivers/8253.h
@@ -1,20 +1,20 @@
/*
-comedi/drivers/8253.h
-Header file for 8253
-
-COMEDI - Linux Control and Measurement Device Interface
-Copyright (C) 2000 David A. Schleef d...@schleef.org
-
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-GNU General Public License for more details.
-*/
+ * comedi/drivers/8253.h
+ * Header file for 8253
+ *
+ * COMEDI - Linux Control and Measurement Device Interface
+ * Copyright (C) 2000 David A. Schleef d...@schleef.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
#ifndef _8253_H
#define _8253_H
@@ -55,7 +55,7 @@ static inline void i8253_cascade_ns_to_timer(int
i8253_osc_base,
/* check for overflow */
divider div1 divider div2
divider * i8253_osc_base divider
- divider * i8253_osc_base i8253_osc_base) {
+ divider * i8253_osc_base i8253_osc_base) {
return;
}
diff --git a/drivers/staging/comedi/drivers/8255.c
b/drivers/staging/comedi/drivers/8255.c
index de273c7..246bf30 100644
--- a/drivers/staging/comedi/drivers/8255.c
+++ b/drivers/staging/comedi/drivers/8255.c
@@ -1,73 +1,77 @@
/*
- comedi/drivers/8255.c
- Driver for 8255
-
- COMEDI - Linux Control and Measurement Device Interface
- Copyright (C) 1998 David A. Schleef d...@schleef.org
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- Driver: 8255
- Description: generic 8255 support
- Devices: [standard] 8255 (8255)
- Author: ds
- Status: works
- Updated: Fri, 7 Jun 2002 12:56:45 -0700
-
- The classic in digital I/O. The 8255 appears in Comedi as a single
- digital I/O subdevice with 24 channels. The channel 0 corresponds
- to the 8255's port A, bit 0; channel 23 corresponds to port C, bit
- 7. Direction configuration is done in blocks, with channels 0-7,
- 8-15, 16-19, and 20-23 making up the 4 blocks. The only 8255 mode
- supported is mode 0.
-
- You should enable compilation this driver if you plan to use a board
- that has an 8255 chip. For multifunction boards, the main driver will
- configure the 8255 subdevice automatically.
-
- This driver also works independently with ISA and PCI cards that
- directly map the 8255 registers to I/O ports, including cards with
- multiple 8255 chips. To configure the driver for such a card, the
- option list should be a list of the I/O port bases for each of the
- 8255 chips. For example,
-
- comedi_config /dev/comedi0 8255 0x200,0x204,0x208,0x20c
-
- Note that most PCI 8255 boards do NOT work with this driver, and
- need a separate driver as a wrapper. For those that do work, the
- I/O port base address can be found
[PATCH 01/94] ARM: shmobile: Add DT and defconfigs to MAINTAINERS
From: Simon Horman horms+rene...@verge.net.au There are a number of DT and defconfig files which are maintained as part of shmobile but have not been listed as such in the MAINTAINERS file. This creates confusion from time to time. Signed-off-by: Simon Horman horms+rene...@verge.net.au Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- MAINTAINERS | 14 ++ 1 file changed, 14 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c411c40..e31c874 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1314,6 +1314,20 @@ W: http://oss.renesas.com Q: http://patchwork.kernel.org/project/linux-sh/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git next S: Supported +F: arch/arm/boot/dts/emev2* +F: arch/arm/boot/dts/r7s* +F: arch/arm/boot/dts/r8a* +F: arch/arm/boot/dts/sh* +F: arch/arm/configs/ape6evm_defconfig +F: arch/arm/configs/armadillo800eva_defconfig +F: arch/arm/configs/bockw_defconfig +F: arch/arm/configs/genmai_defconfig +F: arch/arm/configs/koelsch_defconfig +F: arch/arm/configs/kzm9g_defconfig +F: arch/arm/configs/lager_defconfig +F: arch/arm/configs/mackerel_defconfig +F: arch/arm/configs/marzen_defconfig +F: arch/arm/configs/shmobile_defconfig F: arch/arm/mach-shmobile/ F: drivers/sh/ -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 01/94] ARM: shmobile: Add DT and defconfigs to MAINTAINERS
From: Simon Horman horms+rene...@verge.net.au There are a number of DT and defconfig files which are maintained as part of shmobile but have not been listed as such in the MAINTAINERS file. This creates confusion from time to time. Signed-off-by: Simon Horman horms+rene...@verge.net.au Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- MAINTAINERS | 14 ++ 1 file changed, 14 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c411c40..e31c874 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1314,6 +1314,20 @@ W: http://oss.renesas.com Q: http://patchwork.kernel.org/project/linux-sh/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git next S: Supported +F: arch/arm/boot/dts/emev2* +F: arch/arm/boot/dts/r7s* +F: arch/arm/boot/dts/r8a* +F: arch/arm/boot/dts/sh* +F: arch/arm/configs/ape6evm_defconfig +F: arch/arm/configs/armadillo800eva_defconfig +F: arch/arm/configs/bockw_defconfig +F: arch/arm/configs/genmai_defconfig +F: arch/arm/configs/koelsch_defconfig +F: arch/arm/configs/kzm9g_defconfig +F: arch/arm/configs/lager_defconfig +F: arch/arm/configs/mackerel_defconfig +F: arch/arm/configs/marzen_defconfig +F: arch/arm/configs/shmobile_defconfig F: arch/arm/mach-shmobile/ F: drivers/sh/ -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 05/94] clk: ti: set CLK_SET_RATE_NO_REPARENT for ti,mux-clock
From: Tomi Valkeinen tomi.valkei...@ti.com
When setting the rate of a clock, by default the clock framework will
change the parent of the clock to the most suitable one in
__clk_mux_determine_rate() (most suitable by looking at the clock rate).
This is a rather dangerous default, and causes problems on AM43x when
using display and ethernet. There are multiple ways to select the clock
muxes on AM43x, and some of those clock paths have the same source
clocks for display and ethernet. When changing the clock rate for the
display subsystem, the clock framework decides to change the display mux
from the dedicated display PLL to a shared PLL which is used by the
ethernet, and then changes the rate of the shared PLL, breaking the
ethernet.
As I don't think there ever is a case where we want the clock framework
to automatically change the parent clock of a clock mux, this patch sets
the CLK_SET_RATE_NO_REPARENT for all ti,mux-clocks.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Reviewed-by: Paul Walmsley p...@pwsan.com
Tested-by: Felipe Balbi ba...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
drivers/clk/ti/mux.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/ti/mux.c b/drivers/clk/ti/mux.c
index 0197a47..e9d650e 100644
--- a/drivers/clk/ti/mux.c
+++ b/drivers/clk/ti/mux.c
@@ -160,7 +160,7 @@ static void of_mux_clk_setup(struct device_node *node)
u8 clk_mux_flags = 0;
u32 mask = 0;
u32 shift = 0;
- u32 flags = 0;
+ u32 flags = CLK_SET_RATE_NO_REPARENT;
num_parents = of_clk_get_parent_count(node);
if (num_parents 2) {
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 04/94] clk: ti: am43x: Fix boot with CONFIG_SOC_AM33XX disabled
From: Roger Quadros rog...@ti.com
Define ti_clk_register_dpll_x2() and of_ti_am3_dpll_x2_setup() if
AM43XX is defined.
Fixes the below boot issue.
[2.157258] gpmc_l3_clk not enabled
[2.161194] gpmc_l3_clk not enabled
[2.164896] Division by zero in kernel.
[2.169055] CPU: 0 PID: 321 Comm: kworker/u2:2 Tainted: GW
3.16.0-rc1-8-g4c0e520 #273
[2.178880] Workqueue: deferwq deferred_probe_work_func
[2.184459] [c001477c] (unwind_backtrace) from [c001187c]
(show_stack+0x10/0x14)
[2.192752] [c001187c] (show_stack) from [c0530f28]
(dump_stack+0x80/0x9c)
[2.200486] [c0530f28] (dump_stack) from [c02c867c] (Ldiv0+0x8/0x10)
[2.207678] [c02c867c] (Ldiv0) from [c0022da0]
(gpmc_calc_divider+0x24/0x40)
[2.215490] [c0022da0] (gpmc_calc_divider) from [c0022e20]
(gpmc_cs_set_timings+0x18/0x474)
[2.224783] [c0022e20] (gpmc_cs_set_timings) from [c003069c]
(gpmc_nand_init+0x74/0x1a8)
[2.233791] [c003069c] (gpmc_nand_init) from [c0024668]
(gpmc_probe+0x52c/0x874)
[2.242089] [c0024668] (gpmc_probe) from [c0349218]
(platform_drv_probe+0x18/0x48)
[2.250534] [c0349218] (platform_drv_probe) from [c0347d88]
(driver_probe_device+0x104/0x22c)
[2.259988] [c0347d88] (driver_probe_device) from [c03464dc]
(bus_for_each_drv+0x44/0x8c)
[2.269087] [c03464dc] (bus_for_each_drv) from [c0347c4c]
(device_attach+0x74/0x8c)
[2.277620] [c0347c4c] (device_attach) from [c0347380]
(bus_probe_device+0x88/0xb0)
[2.286074] [c0347380] (bus_probe_device) from [c0347768]
(deferred_probe_work_func+0x60/0x90)
[2.295611] [c0347768] (deferred_probe_work_func) from [c004ef50]
(process_one_work+0x1b4/0x4bc)
[2.305288] [c004ef50] (process_one_work) from [c004f3d4]
(worker_thread+0x148/0x550)
[2.313954] [c004f3d4] (worker_thread) from [c0055a48]
(kthread+0xc8/0xe4)
[2.321628] [c0055a48] (kthread) from [c000e648]
(ret_from_fork+0x14/0x2c)
Signed-off-by: Roger Quadros rog...@ti.com
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Tero Kristo t-kri...@ti.com
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
drivers/clk/ti/dpll.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index abd956d..79791e1 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -161,7 +161,8 @@ cleanup:
}
#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
- defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM33XX)
+ defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM33XX) || \
+ defined(CONFIG_SOC_AM43XX)
/**
* ti_clk_register_dpll_x2 - Registers a DPLLx2 clock
* @node: device node for this clock
@@ -322,7 +323,7 @@ CLK_OF_DECLARE(ti_omap4_dpll_x2_clock,
ti,omap4-dpll-x2-clock,
of_ti_omap4_dpll_x2_setup);
#endif
-#ifdef CONFIG_SOC_AM33XX
+#if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX)
static void __init of_ti_am3_dpll_x2_setup(struct device_node *node)
{
ti_clk_register_dpll_x2(node, dpll_x2_ck_ops, NULL);
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 03/94] clk: ti: dra7: return error code in failure case
From: Julia Lawall julia.law...@lip6.fr
Add a returned error code in the MAX_APLL_WAIT_TRIES case. Remove the
updating of the return variable r to 0 if MAX_APLL_WAIT_TRIES is not yet
reached, because r is already 0 at this point.
Signed-off-by: Julia Lawall julia.law...@lip6.fr
Signed-off-by: Tero Kristo t-kri...@ti.com
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
drivers/clk/ti/apll.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/ti/apll.c b/drivers/clk/ti/apll.c
index 18dbaf12..72d9727 100644
--- a/drivers/clk/ti/apll.c
+++ b/drivers/clk/ti/apll.c
@@ -77,13 +77,11 @@ static int dra7_apll_enable(struct clk_hw *hw)
if (i == MAX_APLL_WAIT_TRIES) {
pr_warn(clock: %s failed transition to '%s'\n,
clk_name, (state) ? locked : bypassed);
- } else {
+ r = -EBUSY;
+ } else
pr_debug(clock: %s transition to '%s' in %d loops\n,
clk_name, (state) ? locked : bypassed, i);
- r = 0;
- }
-
return r;
}
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 12/94] dma: cppi41: handle 0-length packets
From: Daniel Mack zon...@gmail.com
When a 0-length packet is received on the bus, desc-pd0 yields 1,
which confuses the driver's users. This information is clearly wrong
and not in accordance to the datasheet, but it's been observed on an
AM335x board, very reproducible.
Fix this by looking at bit 19 in PD2 of the completed packet. This bit
will tell us if a zero-length packet was received on a queue. If it's
set, ignore the value in PD0 and report a total length of 0 instead.
Signed-off-by: Daniel Mack zon...@gmail.com
Signed-off-by: Vinod Koul vinod.k...@intel.com
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
drivers/dma/cppi41.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index d028f36..8f8b0b6 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -86,6 +86,9 @@
#define USBSS_IRQ_PD_COMP (1 2)
+/* Packet Descriptor */
+#define PD2_ZERO_LENGTH(1 19)
+
struct cppi41_channel {
struct dma_chan chan;
struct dma_async_tx_descriptor txd;
@@ -307,7 +310,7 @@ static irqreturn_t cppi41_irq(int irq, void *data)
__iormb();
while (val) {
- u32 desc;
+ u32 desc, len;
q_num = __fls(val);
val = ~(1 q_num);
@@ -319,9 +322,13 @@ static irqreturn_t cppi41_irq(int irq, void *data)
q_num, desc);
continue;
}
- c-residue = pd_trans_len(c-desc-pd6) -
- pd_trans_len(c-desc-pd0);
+ if (c-desc-pd2 PD2_ZERO_LENGTH)
+ len = 0;
+ else
+ len = pd_trans_len(c-desc-pd0);
+
+ c-residue = pd_trans_len(c-desc-pd6) - len;
dma_cookie_complete(c-txd);
c-txd.callback(c-txd.callback_param);
}
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 09/94] clk: s3c64xx: Hookup SPI clocks correctly
From: Charles Keepax ckee...@opensource.wolfsonmicro.com
In the move to this clock driver the hookups for the SPI clocks were
dropped, which causes my system Cragganmore (s3c6410 based) to be unable
to locate any spibus clocks. This patch adds them back in.
When taking the clock from the epll clock (SCLK) the rates on the SPI
bus are incorrect, this needs further debugging but the hookup here
should be correct and the problem should be else where.
The USBCLK case has been dropped because this requires the USB PHY to be
enabled.
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
drivers/clk/samsung/clk-s3c64xx.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-s3c64xx.c
b/drivers/clk/samsung/clk-s3c64xx.c
index efa16ee..8889ff1c 100644
--- a/drivers/clk/samsung/clk-s3c64xx.c
+++ b/drivers/clk/samsung/clk-s3c64xx.c
@@ -418,8 +418,10 @@ static struct samsung_clock_alias s3c64xx_clock_aliases[]
= {
ALIAS(SCLK_MMC2, s3c-sdhci.2, mmc_busclk.2),
ALIAS(SCLK_MMC1, s3c-sdhci.1, mmc_busclk.2),
ALIAS(SCLK_MMC0, s3c-sdhci.0, mmc_busclk.2),
- ALIAS(SCLK_SPI1, s3c6410-spi.1, spi-bus),
- ALIAS(SCLK_SPI0, s3c6410-spi.0, spi-bus),
+ ALIAS(PCLK_SPI1, s3c6410-spi.1, spi_busclk0),
+ ALIAS(SCLK_SPI1, s3c6410-spi.1, spi_busclk2),
+ ALIAS(PCLK_SPI0, s3c6410-spi.0, spi_busclk0),
+ ALIAS(SCLK_SPI0, s3c6410-spi.0, spi_busclk2),
ALIAS(SCLK_AUDIO1, samsung-pcm.1, audio-bus),
ALIAS(SCLK_AUDIO1, samsung-i2s.1, audio-bus),
ALIAS(SCLK_AUDIO0, samsung-pcm.0, audio-bus),
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 15/94] clk: sunxi: fix devm_ioremap_resource error detection code
From: Himangi Saraogi himangi...@gmail.com devm_ioremap_resource returns an ERR_PTR value, not NULL, on failure. A simplified version of the semantic match that finds this problem is as follows: // smpl @@ expression e,e1; statement S; @@ *e = devm_ioremap_resource(...); if (!e1) S // /smpl Signed-off-by: Himangi Saraogi himangi...@gmail.com Acked-by: Julia Lawall julia.law...@lip6.fr Acked-by Boris BREZILLON boris.brezil...@free-electrons.com Signed-off-by: Mike Turquette mturque...@linaro.org Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- drivers/clk/sunxi/clk-sun6i-apb0-gates.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/sunxi/clk-sun6i-apb0-gates.c b/drivers/clk/sunxi/clk-sun6i-apb0-gates.c index 44cd27c..670f90d 100644 --- a/drivers/clk/sunxi/clk-sun6i-apb0-gates.c +++ b/drivers/clk/sunxi/clk-sun6i-apb0-gates.c @@ -29,7 +29,7 @@ static int sun6i_a31_apb0_gates_clk_probe(struct platform_device *pdev) r = platform_get_resource(pdev, IORESOURCE_MEM, 0); reg = devm_ioremap_resource(pdev-dev, r); - if (!reg) + if (IS_ERR(reg)) return PTR_ERR(reg); clk_parent = of_clk_get_parent_name(np, 0); -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 11/94] clk: exynos5420: Remove aclk66_peric from the clock tree description
From: Doug Anderson diand...@chromium.org
The aclk66_peric clock is a gate clock with a whole bunch of gates
underneath it. This big gate isn't very useful to include in our
clock tree. If any of the children need to be turned on then the big
gate will need to be on anyway. ...and there are plenty of other big
gates that aren't described in our clock tree, some of which shut off
collections of clocks that have no relationship in the hierarchy so
are hard to model.
aclk66_peric is causing earlyprintk problems since it gets disabled
as part of the boot process, so let's just remove it.
Strangely (and for no good reason) this clock is exported as part of
the common clock bindings. Remove it since there are no in-kernel
device trees using it and no reason anyone out of tree should refer to
it either.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
drivers/clk/samsung/clk-exynos5420.c | 85 +---
include/dt-bindings/clock/exynos5420.h |1 -
2 files changed, 55 insertions(+), 31 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 9d7d7ee..61eccf0 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -890,8 +890,6 @@ static struct samsung_gate_clock exynos5x_gate_clks[]
__initdata = {
GATE_BUS_TOP, 9, CLK_IGNORE_UNUSED, 0),
GATE(0, aclk66_psgen, mout_user_aclk66_psgen,
GATE_BUS_TOP, 10, CLK_IGNORE_UNUSED, 0),
- GATE(CLK_ACLK66_PERIC, aclk66_peric, mout_user_aclk66_peric,
- GATE_BUS_TOP, 11, CLK_IGNORE_UNUSED, 0),
GATE(0, aclk266_isp, mout_user_aclk266_isp,
GATE_BUS_TOP, 13, 0, 0),
GATE(0, aclk166, mout_user_aclk166,
@@ -994,34 +992,61 @@ static struct samsung_gate_clock exynos5x_gate_clks[]
__initdata = {
SRC_MASK_FSYS, 24, CLK_SET_RATE_PARENT, 0),
/* PERIC Block */
- GATE(CLK_UART0, uart0, aclk66_peric, GATE_IP_PERIC, 0, 0, 0),
- GATE(CLK_UART1, uart1, aclk66_peric, GATE_IP_PERIC, 1, 0, 0),
- GATE(CLK_UART2, uart2, aclk66_peric, GATE_IP_PERIC, 2, 0, 0),
- GATE(CLK_UART3, uart3, aclk66_peric, GATE_IP_PERIC, 3, 0, 0),
- GATE(CLK_I2C0, i2c0, aclk66_peric, GATE_IP_PERIC, 6, 0, 0),
- GATE(CLK_I2C1, i2c1, aclk66_peric, GATE_IP_PERIC, 7, 0, 0),
- GATE(CLK_I2C2, i2c2, aclk66_peric, GATE_IP_PERIC, 8, 0, 0),
- GATE(CLK_I2C3, i2c3, aclk66_peric, GATE_IP_PERIC, 9, 0, 0),
- GATE(CLK_USI0, usi0, aclk66_peric, GATE_IP_PERIC, 10, 0, 0),
- GATE(CLK_USI1, usi1, aclk66_peric, GATE_IP_PERIC, 11, 0, 0),
- GATE(CLK_USI2, usi2, aclk66_peric, GATE_IP_PERIC, 12, 0, 0),
- GATE(CLK_USI3, usi3, aclk66_peric, GATE_IP_PERIC, 13, 0, 0),
- GATE(CLK_I2C_HDMI, i2c_hdmi, aclk66_peric, GATE_IP_PERIC, 14, 0, 0),
- GATE(CLK_TSADC, tsadc, aclk66_peric, GATE_IP_PERIC, 15, 0, 0),
- GATE(CLK_SPI0, spi0, aclk66_peric, GATE_IP_PERIC, 16, 0, 0),
- GATE(CLK_SPI1, spi1, aclk66_peric, GATE_IP_PERIC, 17, 0, 0),
- GATE(CLK_SPI2, spi2, aclk66_peric, GATE_IP_PERIC, 18, 0, 0),
- GATE(CLK_I2S1, i2s1, aclk66_peric, GATE_IP_PERIC, 20, 0, 0),
- GATE(CLK_I2S2, i2s2, aclk66_peric, GATE_IP_PERIC, 21, 0, 0),
- GATE(CLK_PCM1, pcm1, aclk66_peric, GATE_IP_PERIC, 22, 0, 0),
- GATE(CLK_PCM2, pcm2, aclk66_peric, GATE_IP_PERIC, 23, 0, 0),
- GATE(CLK_PWM, pwm, aclk66_peric, GATE_IP_PERIC, 24, 0, 0),
- GATE(CLK_SPDIF, spdif, aclk66_peric, GATE_IP_PERIC, 26, 0, 0),
- GATE(CLK_USI4, usi4, aclk66_peric, GATE_IP_PERIC, 28, 0, 0),
- GATE(CLK_USI5, usi5, aclk66_peric, GATE_IP_PERIC, 30, 0, 0),
- GATE(CLK_USI6, usi6, aclk66_peric, GATE_IP_PERIC, 31, 0, 0),
-
- GATE(CLK_KEYIF, keyif, aclk66_peric, GATE_BUS_PERIC, 22, 0, 0),
+ GATE(CLK_UART0, uart0, mout_user_aclk66_peric,
+ GATE_IP_PERIC, 0, 0, 0),
+ GATE(CLK_UART1, uart1, mout_user_aclk66_peric,
+ GATE_IP_PERIC, 1, 0, 0),
+ GATE(CLK_UART2, uart2, mout_user_aclk66_peric,
+ GATE_IP_PERIC, 2, 0, 0),
+ GATE(CLK_UART3, uart3, mout_user_aclk66_peric,
+ GATE_IP_PERIC, 3, 0, 0),
+ GATE(CLK_I2C0, i2c0, mout_user_aclk66_peric,
+ GATE_IP_PERIC, 6, 0, 0),
+ GATE(CLK_I2C1, i2c1, mout_user_aclk66_peric,
+ GATE_IP_PERIC, 7, 0, 0),
+ GATE(CLK_I2C2, i2c2, mout_user_aclk66_peric,
+ GATE_IP_PERIC, 8, 0, 0),
+ GATE(CLK_I2C3, i2c3, mout_user_aclk66_peric,
+ GATE_IP_PERIC, 9, 0, 0),
+ GATE(CLK_USI0, usi0, mout_user_aclk66_peric,
+ GATE_IP_PERIC, 10, 0, 0),
+ GATE(CLK_USI1, usi1, mout_user_aclk66_peric,
+ GATE_IP_PERIC, 11, 0, 0
[PATCH 32/94] ext4: clarify error count warning messages
From: Theodore Ts'o ty...@mit.edu
Make it clear that values printed are times, and that it is error
since last fsck. Also add note about fsck version required.
Signed-off-by: Pavel Machek pa...@ucw.cz
Signed-off-by: Theodore Ts'o ty...@mit.edu
Reviewed-by: Andreas Dilger adil...@dilger.ca
Cc: sta...@vger.kernel.org
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
fs/ext4/super.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index b9b9aab..3423947 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -2809,10 +2809,11 @@ static void print_daily_error_info(unsigned long arg)
es = sbi-s_es;
if (es-s_error_count)
- ext4_msg(sb, KERN_NOTICE, error count: %u,
+ /* fsck newer than v1.41.13 is needed to clean this condition.
*/
+ ext4_msg(sb, KERN_NOTICE, error count since last fsck: %u,
le32_to_cpu(es-s_error_count));
if (es-s_first_error_time) {
- printk(KERN_NOTICE EXT4-fs (%s): initial error at %u: %.*s:%d,
+ printk(KERN_NOTICE EXT4-fs (%s): initial error at time %u:
%.*s:%d,
sb-s_id, le32_to_cpu(es-s_first_error_time),
(int) sizeof(es-s_first_error_func),
es-s_first_error_func,
@@ -2826,7 +2827,7 @@ static void print_daily_error_info(unsigned long arg)
printk(\n);
}
if (es-s_last_error_time) {
- printk(KERN_NOTICE EXT4-fs (%s): last error at %u: %.*s:%d,
+ printk(KERN_NOTICE EXT4-fs (%s): last error at time %u:
%.*s:%d,
sb-s_id, le32_to_cpu(es-s_last_error_time),
(int) sizeof(es-s_last_error_func),
es-s_last_error_func,
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 22/94] ARM: dts: fix pwm-cells in pwm node for exynos4
From: Jaewon Kim jaewon02@samsung.com pwm-cells should be 3. Third cell is optional PWM flags. And This flag supported by this binding is PWM_POLARITY_INVERTED. Signed-off-by: Jaewon Kim jaewon02@samsung.com Reviewed-by: Sachin Kamat sachin.ka...@samsung.com Signed-off-by: Kukjin Kim kgene@samsung.com Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- arch/arm/boot/dts/exynos4.dtsi |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index fbaf426..17b22e9 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -554,7 +554,7 @@ interrupts = 0 37 0, 0 38 0, 0 39 0, 0 40 0, 0 41 0; clocks = clock CLK_PWM; clock-names = timers; - #pwm-cells = 2; + #pwm-cells = 3; status = disabled; }; -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 24/94] clocksource: exynos_mct: Register the timer for stable udelay
From: Amit Daniel Kachhap amit.dan...@samsung.com
This patch registers the exynos mct clocksource as the current timer
as it has constant clock rate. This will generate correct udelay for
the exynos platform and avoid using unnecessary calibrated
jiffies. This change has been tested on exynos5420 based board and
udelay is very close to expected.
Without this patch udelay() on exynos5400 / exynos5800 is wildly
inaccurate due to big.LITTLE not adjusting loops_per_jiffy correctly.
Also without this patch udelay() on exynos5250 can be innacruate
during transitions between frequencies 800 MHz (you'll go 200 MHz -
800 MHz - 300 MHz and will run at 800 MHz for a time with the wrong
loops_per_jiffy).
[dianders: reworked and created version 3]
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Kukjin Kim kgene@samsung.com
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
drivers/clocksource/exynos_mct.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 5ce99c0..ab51bf20a 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -200,10 +200,21 @@ static u64 notrace exynos4_read_sched_clock(void)
return _exynos4_frc_read();
}
+static struct delay_timer exynos4_delay_timer;
+
+static cycles_t exynos4_read_current_timer(void)
+{
+ return _exynos4_frc_read();
+}
+
static void __init exynos4_clocksource_init(void)
{
exynos4_mct_frc_start();
+ exynos4_delay_timer.read_current_timer = exynos4_read_current_timer;
+ exynos4_delay_timer.freq = clk_rate;
+ register_current_timer_delay(exynos4_delay_timer);
+
if (clocksource_register_hz(mct_frc, clk_rate))
panic(%s: can't register clocksource\n, mct_frc.name);
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 21/94] ARM: EXYNOS: Fix the check for non-smp configuration
From: Abhilash Kesavan a.kesa...@samsung.com Commit 1754c42e3db5(ARM: exynos: move sysram info to exynos.c) missed out the CONFIG_ prefix causing exynos_sysram_init() to get called twice for SMP configurations. Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Reviewed-by: Sachin Kamat sachin.ka...@samsug.com Signed-off-by: Kukjin Kim kgene@samsung.com Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- arch/arm/mach-exynos/exynos.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c index f38cf7c..95cad25 100644 --- a/arch/arm/mach-exynos/exynos.c +++ b/arch/arm/mach-exynos/exynos.c @@ -297,7 +297,7 @@ static void __init exynos_dt_machine_init(void) * This is called from smp_prepare_cpus if we've built for SMP, but * we still need to set it up for PM and firmware ops if not. */ - if (!IS_ENABLED(SMP)) + if (!IS_ENABLED(CONFIG_SMP)) exynos_sysram_init(); exynos_cpuidle_init(); -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 82/94] ext4: fix a potential deadlock in __ext4_es_shrink()
From: Theodore Ts'o ty...@mit.edu
This fixes the following lockdep complaint:
[ INFO: possible circular locking dependency detected ]
3.16.0-rc2-mm1+ #7 Tainted: G O
---
kworker/u24:0/4356 is trying to acquire lock:
((sbi-s_es_lru_lock)-rlock){+.+.-.}, at: [81285fff]
__ext4_es_shrink+0x4f/0x2e0
but task is already holding lock:
(ei-i_es_lock){-.}, at: [81286961]
ext4_es_insert_extent+0x71/0x180
which lock already depends on the new lock.
Possible unsafe locking scenario:
CPU0CPU1
lock(ei-i_es_lock);
lock((sbi-s_es_lru_lock)-rlock);
lock(ei-i_es_lock);
lock((sbi-s_es_lru_lock)-rlock);
*** DEADLOCK ***
6 locks held by kworker/u24:0/4356:
#0: (writeback){.+.+.+}, at: [81071d00]
process_one_work+0x180/0x560
#1: (((wb-dwork)-work)){+.+.+.}, at: [81071d00]
process_one_work+0x180/0x560
#2: (type-s_umount_key#22){++}, at: [811a9c74]
grab_super_passive+0x44/0x90
#3: (jbd2_handle){+.+...}, at: [812979f9]
start_this_handle+0x189/0x5f0
#4: (ei-i_data_sem){..}, at: [81247062]
ext4_map_blocks+0x132/0x550
#5: (ei-i_es_lock){-.}, at: [81286961]
ext4_es_insert_extent+0x71/0x180
stack backtrace:
CPU: 0 PID: 4356 Comm: kworker/u24:0 Tainted: G O 3.16.0-rc2-mm1+ #7
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Workqueue: writeback bdi_writeback_workfn (flush-253:0)
8213dce0 880014b07538 815df0bb 0007
8213e040 880014b07588 815db3dd 880014b07568
880014b07610 88003b868930 88003b868908 88003b868930
Call Trace:
[815df0bb] dump_stack+0x4e/0x68
[815db3dd] print_circular_bug+0x1fb/0x20c
[810a7a3e] __lock_acquire+0x163e/0x1d00
[815e89dc] ? retint_restore_args+0xe/0xe
[815ddc7b] ? __slab_alloc+0x4a8/0x4ce
[81285fff] ? __ext4_es_shrink+0x4f/0x2e0
[810a8707] lock_acquire+0x87/0x120
[81285fff] ? __ext4_es_shrink+0x4f/0x2e0
[8128592d] ? ext4_es_free_extent+0x5d/0x70
[815e6f09] _raw_spin_lock+0x39/0x50
[81285fff] ? __ext4_es_shrink+0x4f/0x2e0
[8119760b] ? kmem_cache_alloc+0x18b/0x1a0
[81285fff] __ext4_es_shrink+0x4f/0x2e0
[812869b8] ext4_es_insert_extent+0xc8/0x180
[812470f4] ext4_map_blocks+0x1c4/0x550
[8124c4c4] ext4_writepages+0x6d4/0xd00
...
Reported-by: Minchan Kim minc...@kernel.org
Signed-off-by: Theodore Ts'o ty...@mit.edu
Reported-by: Minchan Kim minc...@kernel.org
Cc: sta...@vger.kernel.org
Cc: Zheng Liu gnehzuil@gmail.com
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
fs/ext4/extents_status.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c
index 3f5c188..0b7e28e 100644
--- a/fs/ext4/extents_status.c
+++ b/fs/ext4/extents_status.c
@@ -966,10 +966,10 @@ retry:
continue;
}
- if (ei-i_es_lru_nr == 0 || ei == locked_ei)
+ if (ei-i_es_lru_nr == 0 || ei == locked_ei ||
+ !write_trylock(ei-i_es_lock))
continue;
- write_lock(ei-i_es_lock);
shrunk = __es_try_to_reclaim_extents(ei, nr_to_scan);
if (ei-i_es_lru_nr == 0)
list_del_init(ei-i_es_lru);
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 36/94] ARM: DRA7: hwmod: Fixup SATA hwmod
From: Roger Quadros rog...@ti.com
Get rid of optional clock as that is now managed by the
AHCI platform driver.
Correct .mpu_rt_idx to 1 as the module register space (SYSCONFIG..)
is passed as the second memory resource in the device tree.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
Tested-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 20b4398..1209266 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1268,9 +1268,6 @@ static struct omap_hwmod_class dra7xx_sata_hwmod_class = {
};
/* sata */
-static struct omap_hwmod_opt_clk sata_opt_clks[] = {
- { .role = ref_clk, .clk = sata_ref_clk },
-};
static struct omap_hwmod dra7xx_sata_hwmod = {
.name = sata,
@@ -1278,6 +1275,7 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
.clkdm_name = l3init_clkdm,
.flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk = func_48m_fclk,
+ .mpu_rt_idx = 1,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
@@ -1285,8 +1283,6 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
.modulemode = MODULEMODE_SWCTRL,
},
},
- .opt_clks = sata_opt_clks,
- .opt_clks_cnt = ARRAY_SIZE(sata_opt_clks),
};
/*
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 28/94] iio: hid-sensor-als: Fix return values
From: Sachin Kamat sachin.ka...@samsung.com IIO_CHAN_INFO_SAMP_FREQ and IIO_CHAN_INFO_HYSTERESIS cases ignored the actual return values (which could be -EINVAL) and instead returned IIO_VAL_INT_PLUS_MICRO always. Return the actual value obtained from the functions. Both functions return IIO_VAL_INT_PLUS_MICRO upon success. Signed-off-by: Sachin Kamat sachin.ka...@samsung.com Cc: Srinivas Pandruvada srinivas.pandruv...@linux.intel.com Signed-off-by: Jonathan Cameron ji...@kernel.org Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- drivers/iio/light/hid-sensor-als.c |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c index f34c943..96e71e1 100644 --- a/drivers/iio/light/hid-sensor-als.c +++ b/drivers/iio/light/hid-sensor-als.c @@ -79,7 +79,6 @@ static int als_read_raw(struct iio_dev *indio_dev, struct als_state *als_state = iio_priv(indio_dev); int report_id = -1; u32 address; - int ret; int ret_type; s32 poll_value; @@ -129,14 +128,12 @@ static int als_read_raw(struct iio_dev *indio_dev, ret_type = IIO_VAL_INT; break; case IIO_CHAN_INFO_SAMP_FREQ: - ret = hid_sensor_read_samp_freq_value( + ret_type = hid_sensor_read_samp_freq_value( als_state-common_attributes, val, val2); - ret_type = IIO_VAL_INT_PLUS_MICRO; break; case IIO_CHAN_INFO_HYSTERESIS: - ret = hid_sensor_read_raw_hyst_value( + ret_type = hid_sensor_read_raw_hyst_value( als_state-common_attributes, val, val2); - ret_type = IIO_VAL_INT_PLUS_MICRO; break; default: ret_type = -EINVAL; -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 77/94] Documentation/Changes: clean up mcelog paragraph
From: Paul Bolle pebo...@tiscali.nl The paragraph on mcelog currently describes kernel v2.6.31. In that kernel the mce code (for i386, that is) was in transition. Ever since v2.6.32 the situation is much simpler (eg, mcelog is now needed to process events on almost all x86 machines, i386 and x86-64). Since this document is designed to provide a list of the minimum levels of software necessary to run the 3.0 kernels let's just describe that situation. Signed-off-by: Paul Bolle pebo...@tiscali.nl Acked-by: Andi Kleen a...@linux.intel.com Signed-off-by: Randy Dunlap rdun...@infradead.org Signed-off-by: Linus Torvalds torva...@linux-foundation.org Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- Documentation/Changes |9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/Documentation/Changes b/Documentation/Changes index 2254db0..227bec8 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -280,12 +280,9 @@ that is possible. mcelog -- -In Linux 2.6.31+ the i386 kernel needs to run the mcelog utility -as a regular cronjob similar to the x86-64 kernel to process and log -machine check events when CONFIG_X86_NEW_MCE is enabled. Machine check -events are errors reported by the CPU. Processing them is strongly encouraged. -All x86-64 kernels since 2.6.4 require the mcelog utility to -process machine checks. +On x86 kernels the mcelog utility is needed to process and log machine check +events when CONFIG_X86_MCE is enabled. Machine check events are errors reported +by the CPU. Processing them is strongly encouraged. Getting updated software -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 19/94] clk: qcom: HDMI source sel is 3 not 2
From: Stephen Boyd sb...@codeaurora.org
The HDMI PLL input to the tv mux is supposed to be 3, not 2. Fix
the code so that we can properly select the HDMI PLL.
Fixes: 6d00b56fe clk: qcom: Add support for MSM8960's multimedia clock
controller (MMCC)
Reported-by: Rob Clark robdcl...@gmail.com
Signed-off-by: Stephen Boyd sb...@codeaurora.org
Signed-off-by: Mike Turquette mturque...@linaro.org
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
drivers/clk/qcom/mmcc-msm8960.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/mmcc-msm8960.c b/drivers/clk/qcom/mmcc-msm8960.c
index 12f3c0b..4c449b3 100644
--- a/drivers/clk/qcom/mmcc-msm8960.c
+++ b/drivers/clk/qcom/mmcc-msm8960.c
@@ -1209,7 +1209,7 @@ static struct clk_branch rot_clk = {
static u8 mmcc_pxo_hdmi_map[] = {
[P_PXO] = 0,
- [P_HDMI_PLL]= 2,
+ [P_HDMI_PLL]= 3,
};
static const char *mmcc_pxo_hdmi[] = {
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 90/94] Staging: comedi: 8253.h fixed by removing 'return' from generic func
Signed-off-by: Sam Asadi asadi.sam...@gmail.com
modified: drivers/staging/comedi/drivers/8253.h
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
drivers/staging/comedi/drivers/8253.h |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers/8253.h
b/drivers/staging/comedi/drivers/8253.h
index 5829b46..f6b8607 100644
--- a/drivers/staging/comedi/drivers/8253.h
+++ b/drivers/staging/comedi/drivers/8253.h
@@ -55,7 +55,7 @@ static inline void i8253_cascade_ns_to_timer(int
i8253_osc_base,
/* check for overflow */
divider div1 divider div2
divider * i8253_osc_base divider
- divider * i8253_osc_base i8253_osc_base) {
+ divider * i8253_osc_base i8253_osc_base) {
return;
}
@@ -118,7 +118,6 @@ static inline void i8253_cascade_ns_to_timer(int
i8253_osc_base,
/* masking is done since counter maps zero to 0x1 */
*d1 = div1 0x;
*d2 = div2 0x;
- return;
}
#ifndef CMDTEST
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 86/94] parisc: drop unused defines and header includes
From: Helge Deller del...@gmx.de Signed-off-by: Helge Deller del...@gmx.de Cc: sta...@vger.kernel.org # 3.13+ Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- arch/parisc/kernel/sys_parisc32.c | 36 1 file changed, 36 deletions(-) diff --git a/arch/parisc/kernel/sys_parisc32.c b/arch/parisc/kernel/sys_parisc32.c index ec741fe..93c1963 100644 --- a/arch/parisc/kernel/sys_parisc32.c +++ b/arch/parisc/kernel/sys_parisc32.c @@ -12,44 +12,8 @@ #include linux/compat.h #include linux/kernel.h -#include linux/sched.h -#include linux/fs.h -#include linux/mm.h -#include linux/file.h -#include linux/signal.h -#include linux/resource.h -#include linux/times.h -#include linux/time.h -#include linux/smp.h -#include linux/sem.h -#include linux/shm.h -#include linux/slab.h -#include linux/uio.h -#include linux/ncp_fs.h -#include linux/poll.h -#include linux/personality.h -#include linux/stat.h -#include linux/highmem.h -#include linux/highuid.h -#include linux/mman.h -#include linux/binfmts.h -#include linux/namei.h -#include linux/vfs.h -#include linux/ptrace.h -#include linux/swap.h #include linux/syscalls.h -#include asm/types.h -#include asm/uaccess.h -#include asm/mmu_context.h - -#undef DEBUG - -#ifdef DEBUG -#define DBG(x) printk x -#else -#define DBG(x) -#endif asmlinkage long sys32_unimplemented(int r26, int r25, int r24, int r23, int r22, int r21, int r20) -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 88/94] clk: spear3xx: Set proper clock parent of uart1/2
From: Thomas Gleixner t...@linutronix.de
The uarts only work when the parent is ras_ahb_clk. The stale 3.5
based ST tree does this in the board file.
Add it to the clk init function. Not pretty, but the mess there is
amazing anyway.
Signed-off-by: Thomas Gleixner t...@linutronix.de
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Mike Turquette mturque...@linaro.org
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
drivers/clk/spear/spear3xx_clock.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/spear/spear3xx_clock.c
b/drivers/clk/spear/spear3xx_clock.c
index 125eba8..bb5f387 100644
--- a/drivers/clk/spear/spear3xx_clock.c
+++ b/drivers/clk/spear/spear3xx_clock.c
@@ -245,7 +245,8 @@ static const char *smii0_parents[] = { smii_125m_pad,
ras_pll2_clk,
ras_syn0_gclk, };
static const char *uartx_parents[] = { ras_syn1_gclk, ras_apb_clk, };
-static void __init spear320_clk_init(void __iomem *soc_config_base)
+static void __init spear320_clk_init(void __iomem *soc_config_base,
+struct clk *ras_apb_clk)
{
struct clk *clk;
@@ -342,6 +343,8 @@ static void __init spear320_clk_init(void __iomem
*soc_config_base)
SPEAR320_CONTROL_REG, UART1_PCLK_SHIFT, UART1_PCLK_MASK,
0, _lock);
clk_register_clkdev(clk, NULL, a300.serial);
+ /* Enforce ras_apb_clk */
+ clk_set_parent(clk, ras_apb_clk);
clk = clk_register_mux(NULL, uart2_clk, uartx_parents,
ARRAY_SIZE(uartx_parents),
@@ -349,6 +352,8 @@ static void __init spear320_clk_init(void __iomem
*soc_config_base)
SPEAR320_EXT_CTRL_REG, SPEAR320_UART2_PCLK_SHIFT,
SPEAR320_UARTX_PCLK_MASK, 0, _lock);
clk_register_clkdev(clk, NULL, a400.serial);
+ /* Enforce ras_apb_clk */
+ clk_set_parent(clk, ras_apb_clk);
clk = clk_register_mux(NULL, uart3_clk, uartx_parents,
ARRAY_SIZE(uartx_parents),
@@ -379,12 +384,12 @@ static void __init spear320_clk_init(void __iomem
*soc_config_base)
clk_register_clkdev(clk, NULL, 6010.serial);
}
#else
-static inline void spear320_clk_init(void __iomem *soc_config_base) { }
+static inline void spear320_clk_init(void __iomem *sb, struct clk *rc) { }
#endif
void __init spear3xx_clk_init(void __iomem *misc_base, void __iomem
*soc_config_base)
{
- struct clk *clk, *clk1;
+ struct clk *clk, *clk1, *ras_apb_clk;
clk = clk_register_fixed_rate(NULL, osc_32k_clk, NULL, CLK_IS_ROOT,
32000);
@@ -613,6 +618,7 @@ void __init spear3xx_clk_init(void __iomem *misc_base, void
__iomem *soc_config_
clk = clk_register_gate(NULL, ras_apb_clk, apb_clk, 0, RAS_CLK_ENB,
RAS_APB_CLK_ENB, 0, _lock);
clk_register_clkdev(clk, ras_apb_clk, NULL);
+ ras_apb_clk = clk;
clk = clk_register_gate(NULL, ras_32k_clk, osc_32k_clk, 0,
RAS_CLK_ENB, RAS_32K_CLK_ENB, 0, _lock);
@@ -659,5 +665,5 @@ void __init spear3xx_clk_init(void __iomem *misc_base, void
__iomem *soc_config_
else if (of_machine_is_compatible(st,spear310))
spear310_clk_init();
else if (of_machine_is_compatible(st,spear320))
- spear320_clk_init(soc_config_base);
+ spear320_clk_init(soc_config_base, ras_apb_clk);
}
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 69/94] serial: sh-sci: Add device tree support for r8a7{778, 740, 3a4} and sh73a0
From: Simon Horman horms+rene...@verge.net.au Simply document new compat strings. There appears to be no need for a driver updates. Signed-off-by: Simon Horman horms+rene...@verge.net.au Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- Documentation/devicetree/bindings/serial/renesas,sci-serial.txt |7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index 64fd7de..b355660 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt @@ -4,6 +4,13 @@ Required properties: - compatible: Must contain one of the following: +- renesas,scifa-sh73a0 for SH73A0 (SH-Mobile AG5) SCIFA compatible UART. +- renesas,scifb-sh73a0 for SH73A0 (SH-Mobile AG5) SCIFB compatible UART. +- renesas,scifa-r8a73a4 for R8A73A4 (R-Mobile APE6) SCIFA compatible UART. +- renesas,scifb-r8a73a4 for R8A73A4 (R-Mobile APE6) SCIFB compatible UART. +- renesas,scifa-r8a7740 for R8A7740 (R-Mobile A1) SCIFA compatible UART. +- renesas,scifb-r8a7740 for R8A7740 (R-Mobile A1) SCIFB compatible UART. +- renesas,scif-r8a7778 for R8A7778 (R-Car M1) SCIF compatible UART. - renesas,scif-r8a7779 for R8A7779 (R-Car H1) SCIF compatible UART. - renesas,scif-r8a7790 for R8A7790 (R-Car H2) SCIF compatible UART. - renesas,scifa-r8a7790 for R8A7790 (R-Car H2) SCIFA compatible UART. -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 91/94] Staging: comedi: 8255: fixed by adding an empthy line
fixed a coding style issue. Signed-off-by: Sam Asadi asadi.sam...@gmail.com modified: drivers/staging/comedi/drivers/8255.c Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- drivers/staging/comedi/drivers/8255.c | 150 - 1 file changed, 74 insertions(+), 76 deletions(-) diff --git a/drivers/staging/comedi/drivers/8255.c b/drivers/staging/comedi/drivers/8255.c index 46113a3..de273c7 100644 --- a/drivers/staging/comedi/drivers/8255.c +++ b/drivers/staging/comedi/drivers/8255.c @@ -1,77 +1,73 @@ /* -comedi/drivers/8255.c -Driver for 8255 - -COMEDI - Linux Control and Measurement Device Interface -Copyright (C) 1998 David A. Schleef d...@schleef.org - -This program is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2 of the License, or -(at your option) any later version. - -This program is distributed in the hope that it will be useful, -but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -GNU General Public License for more details. + comedi/drivers/8255.c + Driver for 8255 + + COMEDI - Linux Control and Measurement Device Interface + Copyright (C) 1998 David A. Schleef d...@schleef.org + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + Driver: 8255 + Description: generic 8255 support + Devices: [standard] 8255 (8255) + Author: ds + Status: works + Updated: Fri, 7 Jun 2002 12:56:45 -0700 + + The classic in digital I/O. The 8255 appears in Comedi as a single + digital I/O subdevice with 24 channels. The channel 0 corresponds + to the 8255's port A, bit 0; channel 23 corresponds to port C, bit + 7. Direction configuration is done in blocks, with channels 0-7, + 8-15, 16-19, and 20-23 making up the 4 blocks. The only 8255 mode + supported is mode 0. + + You should enable compilation this driver if you plan to use a board + that has an 8255 chip. For multifunction boards, the main driver will + configure the 8255 subdevice automatically. + + This driver also works independently with ISA and PCI cards that + directly map the 8255 registers to I/O ports, including cards with + multiple 8255 chips. To configure the driver for such a card, the + option list should be a list of the I/O port bases for each of the + 8255 chips. For example, + + comedi_config /dev/comedi0 8255 0x200,0x204,0x208,0x20c + + Note that most PCI 8255 boards do NOT work with this driver, and + need a separate driver as a wrapper. For those that do work, the + I/O port base address can be found in the output of 'lspci -v'. + + This file contains an exported subdevice for driving an 8255. + + To use this subdevice as part of another driver, you need to + set up the subdevice in the attach function of the driver by + calling: + + subdev_8255_init(device, subdevice, io_function, iobase) + + device and subdevice are pointers to the device and subdevice + structures. io_function will be called to provide the + low-level input/output to the device, i.e., actual register + access. io_function will be called with the value of iobase + as the last parameter. If the 8255 device is mapped as 4 + consecutive I/O ports, you can use NULL for io_function + and the I/O port base for iobase, and an internal function will + handle the register access. + + In addition, if the main driver handles interrupts, you can + enable commands on the subdevice by calling subdev_8255_init_irq() + instead. Then, when you get an interrupt that is likely to be + from the 8255, you should call subdev_8255_interrupt(), which + will copy the latched value to a Comedi buffer. */ -/* -Driver: 8255 -Description: generic 8255 support -Devices: [standard] 8255 (8255) -Author: ds -Status: works -Updated: Fri, 7 Jun 2002 12:56:45 -0700 - -The classic in digital I/O. The 8255 appears in Comedi as a single -digital I/O subdevice with 24 channels. The channel 0 corresponds -to the 8255's port A, bit 0; channel 23 corresponds to port C, bit -7. Direction configuration is done in blocks, with channels 0-7, -8-15, 16-19, and 20-23
[PATCH 35/94] ARM: OMAP3: PRM/CM: Add back macros used by TI DSP/Bridge driver
From: Suman Anna s-a...@ti.com
The commit 7be914f {ARM: OMAP3: PRM/CM: Cleanup unused header} removed
some of the macros used by the TI DSP/Bridge driver. This fixes the
following build errors when trying to build DSP/Bridge driver (disabled
at present), otherwise results in the following build errors:
drivers/staging/tidspbridge/core/tiomap3430.c:531:31: error:
'OMAP3430_AUTO_IVA2_DPLL_SHIFT' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap3430.c:531:31: note: each undeclared
identifier is reported only once for each function it appears in
make[3]: *** [drivers/staging/tidspbridge/core/tiomap3430.o] Error 1
make[3]: *** Waiting for unfinished jobs
drivers/staging/tidspbridge/core/tiomap_io.c: In function 'sm_interrupt_dsp':
drivers/staging/tidspbridge/core/tiomap_io.c:404:31: error:
'OMAP3430_AUTO_IVA2_DPLL_SHIFT' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap_io.c:404:31: note: each undeclared
identifier is reported only once for each function it appears in
drivers/staging/tidspbridge/core/tiomap_io.c:414:12: error:
'OMAP3430_IVA2_DPLL_FREQSEL_SHIFT' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap_io.c:415:12: error:
'OMAP3430_EN_IVA2_DPLL_SHIFT' undeclared (first use in this function)
make[3]: *** [drivers/staging/tidspbridge/core/tiomap_io.o] Error 1
drivers/staging/tidspbridge/core/tiomap3430_pwr.c: In function
'dsp_clk_wakeup_event_ctrl':
drivers/staging/tidspbridge/core/tiomap3430_pwr.c:442:19: error:
'OMAP3430_GRPSEL_GPT5_MASK' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap3430_pwr.c:442:19: note: each undeclared
identifier is reported only once for each function it appears in
drivers/staging/tidspbridge/core/tiomap3430_pwr.c:455:19: error:
'OMAP3430_GRPSEL_GPT6_MASK' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap3430_pwr.c:468:19: error:
'OMAP3430_GRPSEL_GPT7_MASK' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap3430_pwr.c:481:19: error:
'OMAP3430_GRPSEL_GPT8_MASK' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap3430_pwr.c:494:19: error:
'OMAP3430_GRPSEL_MCBSP1_MASK' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap3430_pwr.c:546:19: error:
'OMAP3430_GRPSEL_MCBSP5_MASK' undeclared (first use in this function)
make[3]: *** [drivers/staging/tidspbridge/core/tiomap3430_pwr.o] Error 1
make[2]: *** [drivers/staging/tidspbridge] Error 2
Fixes: 7be914f (ARM: OMAP3: PRM/CM: Cleanup unused header)
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
arch/arm/mach-omap2/cm-regbits-34xx.h |3 +++
arch/arm/mach-omap2/prm-regbits-34xx.h |6 ++
2 files changed, 9 insertions(+)
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 04dab2f..ee6c784 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -26,11 +26,14 @@
#define OMAP3430_EN_WDT3_SHIFT 12
#define OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_MASK (1 0)
#define OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_SHIFT 0
+#define OMAP3430_IVA2_DPLL_FREQSEL_SHIFT 4
#define OMAP3430_IVA2_DPLL_FREQSEL_MASK(0xf 4)
#define OMAP3430_EN_IVA2_DPLL_DRIFTGUARD_SHIFT 3
+#define OMAP3430_EN_IVA2_DPLL_SHIFT0
#define OMAP3430_EN_IVA2_DPLL_MASK (0x7 0)
#define OMAP3430_ST_IVA2_SHIFT 0
#define OMAP3430_ST_IVA2_CLK_MASK (1 0)
+#define OMAP3430_AUTO_IVA2_DPLL_SHIFT 0
#define OMAP3430_AUTO_IVA2_DPLL_MASK (0x7 0)
#define OMAP3430_IVA2_CLK_SRC_SHIFT19
#define OMAP3430_IVA2_CLK_SRC_WIDTH3
diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h
b/arch/arm/mach-omap2/prm-regbits-34xx.h
index 106132d..cbefbd7 100644
--- a/arch/arm/mach-omap2/prm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-34xx.h
@@ -35,6 +35,8 @@
#define OMAP3430_LOGICSTATEST_MASK (1 2)
#define OMAP3430_LASTLOGICSTATEENTERED_MASK(1 2)
#define OMAP3430_LASTPOWERSTATEENTERED_MASK(0x3 0)
+#define OMAP3430_GRPSEL_MCBSP5_MASK(1 10)
+#define OMAP3430_GRPSEL_MCBSP1_MASK(1 9)
#define OMAP3630_GRPSEL_UART4_MASK (1 18)
#define OMAP3430_GRPSEL_GPIO6_MASK (1 17)
#define OMAP3430_GRPSEL_GPIO5_MASK (1 16)
@@ -42,6 +44,10 @@
#define OMAP3430_GRPSEL_GPIO3_MASK (1 14)
#define OMAP3430_GRPSEL_GPIO2_MASK (1 13)
#define OMAP3430_GRPSEL_UART3_MASK (1 11
[PATCH 38/94] ARM: OMAP2+: clock/dpll: fix _dpll_test_fint arithmetics overflow
From: Tero Kristo t-kri...@ti.com
The divider value provided to the _dpll_test_fint can reach value of
256 with J type DPLLs (USB etc.), which causes an overflow with the u8
datatype. Fix this by changing the parameter to be an int instead.
Signed-off-by: Tero Kristo t-kri...@ti.com
[p...@pwsan.com: changed type of 'n' to unsigned int]
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
arch/arm/mach-omap2/clkt_dpll.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index 332af92..67fd26a 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -76,7 +76,7 @@
* (assuming that it is counting N upwards), or -2 if the enclosing loop
* should skip to the next iteration (again assuming N is increasing).
*/
-static int _dpll_test_fint(struct clk_hw_omap *clk, u8 n)
+static int _dpll_test_fint(struct clk_hw_omap *clk, unsigned int n)
{
struct dpll_data *dd;
long fint, fint_min, fint_max;
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 70/94] USB: serial: ftdi_sio: Add Infineon Triboard
From: Michal Sojka sojk...@fel.cvut.cz
This adds support for Infineon TriBoard TC1798 [1]. Only interface 1
is used as serial line (see [2], Figure 8-6).
[1]
http://www.infineon.com/cms/de/product/microcontroller/development-tools-software-and-kits/tricore-tm-development-tools-software-and-kits/starterkits-and-evaluation-boards/starter-kit-tc1798/channel.html?channel=db3a304333b8a7ca0133cfa3d73e4268
[2]
http://www.infineon.com/dgdl/TriBoardManual-TC1798-V10.pdf?folderId=db3a304412b407950112b409ae7c0343fileId=db3a304333b8a7ca0133cfae99fe426a
Signed-off-by: Michal Sojka sojk...@fel.cvut.cz
Cc: Johan Hovold jo...@kernel.org
Cc: stable sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
drivers/usb/serial/ftdi_sio.c |2 ++
drivers/usb/serial/ftdi_sio_ids.h |6 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index bf2e30a..8a3813b 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -945,6 +945,8 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_2_PID) },
{ USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_3_PID) },
{ USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_4_PID) },
+ /* Infineon Devices */
+ { USB_DEVICE_INTERFACE_NUMBER(INFINEON_VID, INFINEON_TRIBOARD_PID, 1) },
{ } /* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index 106cc16..c4777bc 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -584,6 +584,12 @@
#define RATOC_PRODUCT_ID_USB60F0xb020
/*
+ * Infineon Technologies
+ */
+#define INFINEON_VID 0x058b
+#define INFINEON_TRIBOARD_PID 0x0028 /* DAS JTAG TriBoard TC1798 V1.0 */
+
+/*
* Acton Research Corp.
*/
#define ACTON_VID 0x0647 /* Vendor ID */
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 44/94] ARM: OMAP2+: create dsp device only on OMAP3 SoCs
From: Suman Anna s-a...@ti.com
The DSP platform device for TI DSP/Bridge is currently
created unconditionally whenever CONFIG_TIDSPBRIDGE is
enabled. This device should only be created on OMAP34xx/
OMAP36xx SoCs, and not for other OMAP3 derived SoCs or when
booting multi-arch images on other SoCs. So, add a check for
the SoC family both before creating the device and allocating
the carveout memory for the device.
Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
arch/arm/mach-omap2/dsp.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c
index b8208b4..f7492df 100644
--- a/arch/arm/mach-omap2/dsp.c
+++ b/arch/arm/mach-omap2/dsp.c
@@ -29,6 +29,7 @@
#ifdef CONFIG_TIDSPBRIDGE_DVFS
#include omap-pm.h
#endif
+#include soc.h
#include linux/platform_data/dsp-omap.h
@@ -59,6 +60,9 @@ void __init omap_dsp_reserve_sdram_memblock(void)
phys_addr_t size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
phys_addr_t paddr;
+ if (!cpu_is_omap34xx())
+ return;
+
if (!size)
return;
@@ -83,6 +87,9 @@ static int __init omap_dsp_init(void)
int err = -ENOMEM;
struct omap_dsp_platform_data *pdata = omap_dsp_pdata;
+ if (!cpu_is_omap34xx())
+ return 0;
+
pdata-phys_mempool_base = omap_dsp_get_mempool_base();
if (pdata-phys_mempool_base) {
@@ -115,6 +122,9 @@ module_init(omap_dsp_init);
static void __exit omap_dsp_exit(void)
{
+ if (!cpu_is_omap34xx())
+ return;
+
platform_device_unregister(omap_dsp_pdev);
}
module_exit(omap_dsp_exit);
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 52/94] ARM: imx: fix shared gate clock
From: Shawn Guo shawn@freescale.com
Let's say clock A and B are two gate clocks that share the same register
bit in hardware. Therefore they are registered as shared gate clocks
with imx_clk_gate2_shared().
In a scenario that only clock A is enabled by clk_enable(A) while B is
not used, the shared gate will be unexpectedly disabled in hardware.
It happens because clk_enable(A) increments the share_count from 0 to 1,
while clock B is unused to clock core, and therefore the core function
will just disable B by calling clk-ops-disable() directly. The
consequence of that call is share_count is decremented to 0 and the gate
is disabled in hardware, even though clock A is still in use.
The patch fixes the issue by initializing the share_count per hardware
state and returns enable state per share_count from .is_enabled() hook,
in case it's a shared gate.
While at it, add a check in clk_gate2_disable() to ensure it's never
called with a zero share_count.
Reported-by: Fabio Estevam fabio.este...@freescale.com
Fixes: f9f28cdf2167 (ARM: imx: add shared gate clock support)
Signed-off-by: Shawn Guo shawn@freescale.com
Tested-by: Fabio Estevam fabio.este...@freescale.com
Signed-off-by: Olof Johansson o...@lixom.net
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
arch/arm/mach-imx/clk-gate2.c | 31 +++
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-imx/clk-gate2.c b/arch/arm/mach-imx/clk-gate2.c
index 4ba587d..84acdfd 100644
--- a/arch/arm/mach-imx/clk-gate2.c
+++ b/arch/arm/mach-imx/clk-gate2.c
@@ -67,8 +67,12 @@ static void clk_gate2_disable(struct clk_hw *hw)
spin_lock_irqsave(gate-lock, flags);
- if (gate-share_count --(*gate-share_count) 0)
- goto out;
+ if (gate-share_count) {
+ if (WARN_ON(*gate-share_count == 0))
+ goto out;
+ else if (--(*gate-share_count) 0)
+ goto out;
+ }
reg = readl(gate-reg);
reg = ~(3 gate-bit_idx);
@@ -78,19 +82,26 @@ out:
spin_unlock_irqrestore(gate-lock, flags);
}
-static int clk_gate2_is_enabled(struct clk_hw *hw)
+static int clk_gate2_reg_is_enabled(void __iomem *reg, u8 bit_idx)
{
- u32 reg;
- struct clk_gate2 *gate = to_clk_gate2(hw);
+ u32 val = readl(reg);
- reg = readl(gate-reg);
-
- if (((reg gate-bit_idx) 1) == 1)
+ if (((val bit_idx) 1) == 1)
return 1;
return 0;
}
+static int clk_gate2_is_enabled(struct clk_hw *hw)
+{
+ struct clk_gate2 *gate = to_clk_gate2(hw);
+
+ if (gate-share_count)
+ return !!(*gate-share_count);
+ else
+ return clk_gate2_reg_is_enabled(gate-reg, gate-bit_idx);
+}
+
static struct clk_ops clk_gate2_ops = {
.enable = clk_gate2_enable,
.disable = clk_gate2_disable,
@@ -116,6 +127,10 @@ struct clk *clk_register_gate2(struct device *dev, const
char *name,
gate-bit_idx = bit_idx;
gate-flags = clk_gate2_flags;
gate-lock = lock;
+
+ /* Initialize share_count per hardware state */
+ if (share_count)
+ *share_count = clk_gate2_reg_is_enabled(reg, bit_idx) ? 1 : 0;
gate-share_count = share_count;
init.name = name;
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 33/94] ext4: clarify ext4_error message in ext4_mb_generate_buddy_error()
From: Theodore Ts'o ty...@mit.edu
We are spending a lot of time explaining to users what this error
means. Let's try to improve the message to avoid this problem.
Signed-off-by: Theodore Ts'o ty...@mit.edu
Cc: sta...@vger.kernel.org
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
fs/ext4/mballoc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 7f72f50..2dcb936 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -752,8 +752,8 @@ void ext4_mb_generate_buddy(struct super_block *sb,
if (free != grp-bb_free) {
ext4_grp_locked_error(sb, group, 0, 0,
- %u clusters in bitmap, %u in gd;
- block bitmap corrupt.,
+ block bitmap and bg descriptor
+ inconsistent: %u vs %u free clusters,
free, grp-bb_free);
/*
* If we intend to continue, we consider group descriptor
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 50/94] ARM: EXYNOS: Update secondary boot addr for secure mode
From: Sachin Kamat sachin.ka...@linaro.org Almost all Exynos-series of SoCs that run in secure mode don't need additional offset for every CPU, with Exynos4412 being the only exception. Tested on Origen-Quad (Exynos4412) and Arndale-Octa (Exynos5420). While at it, fix the coding style (space around *). Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Signed-off-by: Tushar Behera tushar.beh...@linaro.org Tested-by: Andreas Faerber afaer...@suse.de Signed-off-by: Kukjin Kim kgene@samsung.com Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- arch/arm/mach-exynos/firmware.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c index eb91d23..e8797bb 100644 --- a/arch/arm/mach-exynos/firmware.c +++ b/arch/arm/mach-exynos/firmware.c @@ -57,8 +57,13 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr) boot_reg = sysram_ns_base_addr + 0x1c; - if (!soc_is_exynos4212() !soc_is_exynos3250()) - boot_reg += 4*cpu; + /* +* Almost all Exynos-series of SoCs that run in secure mode don't need +* additional offset for every CPU, with Exynos4412 being the only +* exception. +*/ + if (soc_is_exynos4412()) + boot_reg += 4 * cpu; __raw_writel(boot_addr, boot_reg); return 0; -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 62/94] ARM: dts: Add clock property for mfc_pd in exynos5420
From: Arun Kumar K arun...@samsung.com
Adding the optional clock property for the mfc_pd for
handling the re-parenting while pd on/off.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
arch/arm/boot/dts/exynos5420.dtsi |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 79e9119..1595722 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -260,6 +260,9 @@
mfc_pd: power-domain@10044060 {
compatible = samsung,exynos4210-pd;
reg = 0x10044060 0x20;
+ clocks = clock CLK_FIN_PLL, clock CLK_MOUT_SW_ACLK333,
+ clock CLK_MOUT_USER_ACLK333;
+ clock-names = oscclk, pclk0, clk0;
};
disp_pd: power-domain@100440C0 {
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 31/94] ext4: fix unjournalled bg descriptor while initializing inode bitmap
From: Theodore Ts'o ty...@mit.edu
The first time that we allocate from an uninitialized inode allocation
bitmap, if the block allocation bitmap is also uninitalized, we need
to get write access to the block group descriptor before we start
modifying the block group descriptor flags and updating the free block
count, etc. Otherwise, there is the potential of a bad journal
checksum (if journal checksums are enabled), and of the file system
becoming inconsistent if we crash at exactly the wrong time.
Signed-off-by: Theodore Ts'o ty...@mit.edu
Cc: sta...@vger.kernel.org
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
fs/ext4/ialloc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index a87455d..0840bf3 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -874,6 +874,13 @@ got:
goto out;
}
+ BUFFER_TRACE(group_desc_bh, get_write_access);
+ err = ext4_journal_get_write_access(handle, group_desc_bh);
+ if (err) {
+ ext4_std_error(sb, err);
+ goto out;
+ }
+
/* We may have to initialize the block bitmap if it isn't already */
if (ext4_has_group_desc_csum(sb)
gdp-bg_flags cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {
@@ -910,13 +917,6 @@ got:
}
}
- BUFFER_TRACE(group_desc_bh, get_write_access);
- err = ext4_journal_get_write_access(handle, group_desc_bh);
- if (err) {
- ext4_std_error(sb, err);
- goto out;
- }
-
/* Update the relevant bg descriptor fields */
if (ext4_has_group_desc_csum(sb)) {
int free;
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 46/94] ARM: dts: am335x-evm: Enable the McASP FIFO for audio
From: Peter Ujfalusi peter.ujfal...@ti.com
The use of FIFO in McASP can reduce the risk of audio under/overrun and
lowers the load on the memories since the DMA will operate in bursts.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
arch/arm/boot/dts/am335x-evm.dts |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index ecb2677..e2156a5 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -529,8 +529,8 @@
serial-dir = /* 0: INACTIVE, 1: TX, 2: RX */
0 0 1 2
;
- tx-num-evt = 1;
- rx-num-evt = 1;
+ tx-num-evt = 32;
+ rx-num-evt = 32;
};
tps {
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 54/94] iio: ti_am335x_adc: Fix: Use same step id at FIFOs both ends
From: Jan Kardell jan.kard...@telliq.com Since AI lines could be selected at will (linux-3.11) the sending and receiving ends of the FIFO does not agree about what step is used for a line. It only works if the last lines are used, like 5,6,7, and fails if ie 2,4,6 is selected in DT. Signed-off-by: Jan Kardell jan.kard...@telliq.com Tested-by: Zubair Lutfullah zubair.lutful...@gmail.com Signed-off-by: Jonathan Cameron ji...@kernel.org Cc: sta...@vger.kernel.org Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- drivers/iio/adc/ti_am335x_adc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c index a4db302..d5dc4c6 100644 --- a/drivers/iio/adc/ti_am335x_adc.c +++ b/drivers/iio/adc/ti_am335x_adc.c @@ -374,7 +374,7 @@ static int tiadc_read_raw(struct iio_dev *indio_dev, return -EAGAIN; } } - map_val = chan-channel + TOTAL_CHANNELS; + map_val = adc_dev-channel_step[chan-scan_index]; /* * We check the complete FIFO. We programmed just one entry but in case -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 93/94] Staging: comedi: 3 files revised fixed style issues
3 files in 'staging/comedi/drivers/' revised again
and style issues fixed
Signed-off-by: Sam Asadi asadi.sam...@gmail.com
modified: drivers/staging/comedi/drivers/8253.h
modified: drivers/staging/comedi/drivers/8255.c
modified: drivers/staging/comedi/drivers/adl_pci9118.c
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
drivers/staging/comedi/drivers/8253.h| 34 +++---
drivers/staging/comedi/drivers/8255.c| 154 +-
drivers/staging/comedi/drivers/adl_pci9118.c | 140 +++
3 files changed, 167 insertions(+), 161 deletions(-)
diff --git a/drivers/staging/comedi/drivers/8253.h
b/drivers/staging/comedi/drivers/8253.h
index f6b8607..31d0fc9 100644
--- a/drivers/staging/comedi/drivers/8253.h
+++ b/drivers/staging/comedi/drivers/8253.h
@@ -1,20 +1,20 @@
/*
-comedi/drivers/8253.h
-Header file for 8253
-
-COMEDI - Linux Control and Measurement Device Interface
-Copyright (C) 2000 David A. Schleef d...@schleef.org
-
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-GNU General Public License for more details.
-*/
+ * comedi/drivers/8253.h
+ * Header file for 8253
+ *
+ * COMEDI - Linux Control and Measurement Device Interface
+ * Copyright (C) 2000 David A. Schleef d...@schleef.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
#ifndef _8253_H
#define _8253_H
@@ -55,7 +55,7 @@ static inline void i8253_cascade_ns_to_timer(int
i8253_osc_base,
/* check for overflow */
divider div1 divider div2
divider * i8253_osc_base divider
- divider * i8253_osc_base i8253_osc_base) {
+ divider * i8253_osc_base i8253_osc_base) {
return;
}
diff --git a/drivers/staging/comedi/drivers/8255.c
b/drivers/staging/comedi/drivers/8255.c
index de273c7..246bf30 100644
--- a/drivers/staging/comedi/drivers/8255.c
+++ b/drivers/staging/comedi/drivers/8255.c
@@ -1,73 +1,77 @@
/*
- comedi/drivers/8255.c
- Driver for 8255
-
- COMEDI - Linux Control and Measurement Device Interface
- Copyright (C) 1998 David A. Schleef d...@schleef.org
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- Driver: 8255
- Description: generic 8255 support
- Devices: [standard] 8255 (8255)
- Author: ds
- Status: works
- Updated: Fri, 7 Jun 2002 12:56:45 -0700
-
- The classic in digital I/O. The 8255 appears in Comedi as a single
- digital I/O subdevice with 24 channels. The channel 0 corresponds
- to the 8255's port A, bit 0; channel 23 corresponds to port C, bit
- 7. Direction configuration is done in blocks, with channels 0-7,
- 8-15, 16-19, and 20-23 making up the 4 blocks. The only 8255 mode
- supported is mode 0.
-
- You should enable compilation this driver if you plan to use a board
- that has an 8255 chip. For multifunction boards, the main driver will
- configure the 8255 subdevice automatically.
-
- This driver also works independently with ISA and PCI cards that
- directly map the 8255 registers to I/O ports, including cards with
- multiple 8255 chips. To configure the driver for such a card, the
- option list should be a list of the I/O port bases for each of the
- 8255 chips. For example,
-
- comedi_config /dev/comedi0 8255 0x200,0x204,0x208,0x20c
-
- Note that most PCI 8255 boards do NOT work with this driver, and
- need a separate driver as a wrapper. For those that do work, the
- I/O port base address can
[PATCH 59/94] m68k: Fix boot regression on machines with RAM at non-zero
From: Geert Uytterhoeven ge...@linux-m68k.org My enhancement to store the initial mapping size for later reuse in commit 486df8bc4627bdfc032d11bedcd056cc5343ee62 (m68k: Increase initial mapping to 8 or 16 MiB if possible) broke booting on machines where RAM doesn't start at address zero. Use pc-relative addressing to fix this. Reported-by: Andreas Schwab sch...@linux-m68k.org Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org Tested-by: Andreas Schwab sch...@linux-m68k.org Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- arch/m68k/kernel/head.S |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/m68k/kernel/head.S b/arch/m68k/kernel/head.S index dbb118e..a547884 100644 --- a/arch/m68k/kernel/head.S +++ b/arch/m68k/kernel/head.S @@ -921,7 +921,8 @@ L(nocon): jls 1f lsrl#1,%d1 1: - movel %d1,m68k_init_mapped_size + lea %pc@(m68k_init_mapped_size),%a0 + movel %d1,%a0@ mmu_map #PAGE_OFFSET,%pc@(L(phys_kernel_start)),%d1,\ %pc@(m68k_supervisor_cachemode) -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 74/94] phy: core: Fix error path in phy_create()
From: Roger Quadros rog...@ti.com Prevent resources from being freed twice in case device_add() call fails within phy_create(). Also use ida_simple_remove() instead of ida_remove() as we had used ida_simple_get() to allocate the ida. Cc: 3.13+ sta...@vger.kernel.org # 3.13+ Signed-off-by: Roger Quadros rog...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- drivers/phy/phy-core.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c index c64a2f3..49c4465 100644 --- a/drivers/phy/phy-core.c +++ b/drivers/phy/phy-core.c @@ -614,8 +614,9 @@ struct phy *phy_create(struct device *dev, const struct phy_ops *ops, return phy; put_dev: - put_device(phy-dev); - ida_remove(phy_ida, phy-id); + put_device(phy-dev); /* calls phy_release() which frees resources */ + return ERR_PTR(ret); + free_phy: kfree(phy); return ERR_PTR(ret); @@ -799,7 +800,7 @@ static void phy_release(struct device *dev) phy = to_phy(dev); dev_vdbg(dev, releasing '%s'\n, dev_name(dev)); - ida_remove(phy_ida, phy-id); + ida_simple_remove(phy_ida, phy-id); kfree(phy); } -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 26/94] iio: hid-sensor-accel-3d: Fix return values
From: Sachin Kamat sachin.ka...@samsung.com IIO_CHAN_INFO_SAMP_FREQ and IIO_CHAN_INFO_HYSTERESIS cases ignored the actual return values (which could be -EINVAL) and instead returned IIO_VAL_INT_PLUS_MICRO always. Return the actual value obtained from the functions. Both functions return IIO_VAL_INT_PLUS_MICRO upon success. Signed-off-by: Sachin Kamat sachin.ka...@samsung.com Cc: Srinivas Pandruvada srinivas.pandruv...@linux.intel.com Signed-off-by: Jonathan Cameron ji...@kernel.org Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- drivers/iio/accel/hid-sensor-accel-3d.c |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c b/drivers/iio/accel/hid-sensor-accel-3d.c index 69abf91..54e464e 100644 --- a/drivers/iio/accel/hid-sensor-accel-3d.c +++ b/drivers/iio/accel/hid-sensor-accel-3d.c @@ -110,7 +110,6 @@ static int accel_3d_read_raw(struct iio_dev *indio_dev, struct accel_3d_state *accel_state = iio_priv(indio_dev); int report_id = -1; u32 address; - int ret; int ret_type; s32 poll_value; @@ -151,14 +150,12 @@ static int accel_3d_read_raw(struct iio_dev *indio_dev, ret_type = IIO_VAL_INT; break; case IIO_CHAN_INFO_SAMP_FREQ: - ret = hid_sensor_read_samp_freq_value( + ret_type = hid_sensor_read_samp_freq_value( accel_state-common_attributes, val, val2); - ret_type = IIO_VAL_INT_PLUS_MICRO; break; case IIO_CHAN_INFO_HYSTERESIS: - ret = hid_sensor_read_raw_hyst_value( + ret_type = hid_sensor_read_raw_hyst_value( accel_state-common_attributes, val, val2); - ret_type = IIO_VAL_INT_PLUS_MICRO; break; default: ret_type = -EINVAL; -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 80/94] DocBook: fix various typos
From: Masanari Iida standby2...@gmail.com This patch fixed spelling typo in various template files within Documentation/Docbook. Signed-off-by: Masanari Iida standby2...@gmail.com Signed-off-by: Randy Dunlap rdun...@infradead.org Signed-off-by: Linus Torvalds torva...@linux-foundation.org Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- Documentation/DocBook/gadget.tmpl |2 +- Documentation/DocBook/genericirq.tmpl |4 ++-- Documentation/DocBook/kernel-locking.tmpl |2 +- Documentation/DocBook/libata.tmpl |6 +++--- Documentation/DocBook/media_api.tmpl |2 +- Documentation/DocBook/regulator.tmpl |2 +- Documentation/DocBook/uio-howto.tmpl |4 ++-- Documentation/DocBook/usb.tmpl|2 +- Documentation/DocBook/writing-an-alsa-driver.tmpl |2 +- 9 files changed, 13 insertions(+), 13 deletions(-) diff --git a/Documentation/DocBook/gadget.tmpl b/Documentation/DocBook/gadget.tmpl index 4017f14..2c425d7 100644 --- a/Documentation/DocBook/gadget.tmpl +++ b/Documentation/DocBook/gadget.tmpl @@ -708,7 +708,7 @@ hardware level details could be very different. paraSystems need specialized hardware support to implement OTG, notably including a special emphasisMini-AB/emphasis jack -and associated transciever to support emphasisDual-Role/emphasis +and associated transceiver to support emphasisDual-Role/emphasis operation: they can act either as a host, using the standard Linux-USB host side driver stack, diff --git a/Documentation/DocBook/genericirq.tmpl b/Documentation/DocBook/genericirq.tmpl index 46347f6..59fb5c0 100644 --- a/Documentation/DocBook/genericirq.tmpl +++ b/Documentation/DocBook/genericirq.tmpl @@ -182,7 +182,7 @@ para Each interrupt is described by an interrupt descriptor structure irq_desc. The interrupt is referenced by an 'unsigned int' numeric - value which selects the corresponding interrupt decription structure + value which selects the corresponding interrupt description structure in the descriptor structures array. The descriptor structure contains status information and pointers to the interrupt flow method and the interrupt chip structure @@ -470,7 +470,7 @@ if (desc-irq_data.chip-irq_eoi) para To avoid copies of identical implementations of IRQ chips the core provides a configurable generic interrupt chip - implementation. Developers should check carefuly whether the + implementation. Developers should check carefully whether the generic chip fits their needs before implementing the same functionality slightly differently themselves. /para diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl index 19f2a5a..e584ee1 100644 --- a/Documentation/DocBook/kernel-locking.tmpl +++ b/Documentation/DocBook/kernel-locking.tmpl @@ -1760,7 +1760,7 @@ as it would be on UP. /para para -There is a furthur optimization possible here: remember our original +There is a further optimization possible here: remember our original cache code, where there were no reference counts and the caller simply held the lock whenever using the object? This is still possible: if you hold the lock, no one can delete the object, so you don't need to diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl index deb71ba..d7fcdc5 100644 --- a/Documentation/DocBook/libata.tmpl +++ b/Documentation/DocBook/libata.tmpl @@ -677,7 +677,7 @@ and other resources, etc. listitem para - ATA_QCFLAG_ACTIVE is clared from qc-flags. + ATA_QCFLAG_ACTIVE is cleared from qc-flags. /para /listitem @@ -708,7 +708,7 @@ and other resources, etc. listitem para - qc-waiting is claread amp; completed (in that order). + qc-waiting is cleared amp; completed (in that order). /para /listitem @@ -1163,7 +1163,7 @@ and other resources, etc. para Once sense data is acquired, this type of errors can be - handled similary to other SCSI errors. Note that sense data + handled similarly to other SCSI errors. Note that sense data may indicate ATA bus error (e.g. Sense Key 04h HARDWARE ERROR amp;amp; ASC/ASCQ 47h/00h SCSI PARITY ERROR). In such cases, the error should be considered as an ATA bus error and diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index 4decb46..03f9a1f 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -68,7 +68,7 @@ several digital tv standards. While it is called as DVB API, in fact it covers several different video standards including DVB-T, DVB-S, DVB-C and ATSC. The API is currently being
[PATCH 43/94] ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on
From: Roger Quadros rog...@ti.com After clarification from the hardware team it was found that this 1.8V PHY supply can't be switched OFF when SoC is Active. Since the PHY IPs don't contain isolation logic built in the design to allow the power rail to be switched off, there is a very high risk of IP reliability and additional leakage paths which can result in additional power consumption. The only scenario where this rail can be switched off is part of Power on reset sequencing, but it needs to be kept always-on during operation. This patch is required for proper functionality of USB, SATA and PCIe on DRA7-evm. CC: Rajendra Nayak rna...@ti.com CC: Tero Kristo t-kri...@ti.com Signed-off-by: Roger Quadros rog...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com Signed-off-by: sam-the-6 asadi.sam...@gmail.com --- arch/arm/boot/dts/dra7-evm.dts |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts index 4adc280..8308954 100644 --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -240,6 +240,7 @@ regulator-name = ldo3; regulator-min-microvolt = 180; regulator-max-microvolt = 180; + regulator-always-on; regulator-boot-on; }; -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 39/94] iio:tcs3472: Check for buffer enabled and locking
From: Peter Meerwald p.meerw...@bct-electronic.com
Signed-off-by: Peter Meerwald pme...@pmeerw.net
Signed-off-by: Jonathan Cameron ji...@kernel.org
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
drivers/iio/light/tcs3472.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/light/tcs3472.c b/drivers/iio/light/tcs3472.c
index fe063a0..7525699 100644
--- a/drivers/iio/light/tcs3472.c
+++ b/drivers/iio/light/tcs3472.c
@@ -52,6 +52,7 @@
struct tcs3472_data {
struct i2c_client *client;
+ struct mutex lock;
u8 enable;
u8 control;
u8 atime;
@@ -116,10 +117,17 @@ static int tcs3472_read_raw(struct iio_dev *indio_dev,
switch (mask) {
case IIO_CHAN_INFO_RAW:
+ if (iio_buffer_enabled(indio_dev))
+ return -EBUSY;
+
+ mutex_lock(data-lock);
ret = tcs3472_req_data(data);
- if (ret 0)
+ if (ret 0) {
+ mutex_unlock(data-lock);
return ret;
+ }
ret = i2c_smbus_read_word_data(data-client, chan-address);
+ mutex_unlock(data-lock);
if (ret 0)
return ret;
*val = ret;
@@ -255,6 +263,7 @@ static int tcs3472_probe(struct i2c_client *client,
data = iio_priv(indio_dev);
i2c_set_clientdata(client, indio_dev);
data-client = client;
+ mutex_init(data-lock);
indio_dev-dev.parent = client-dev;
indio_dev-info = tcs3472_info;
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 75/94] phy: omap-usb2: Balance pm_runtime_enable() on probe failure and remove
From: Roger Quadros rog...@ti.com
If probe fails then we need to call pm_runtime_disable() to balance
out the previous pm_runtime_enable() call. Else it will cause
unbalanced pm_runtime_enable() call in the succeding probe call.
This anomaly was observed when the call to devm_phy_create() failed
with -EPROBE_DEFER.
Balance out the pm_runtime_enable() call in .remove() as well.
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: sam-the-6 asadi.sam...@gmail.com
---
drivers/phy/phy-omap-usb2.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 2063d54..34b3961 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -262,7 +262,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
otg-phy= phy-phy;
platform_set_drvdata(pdev, phy);
- pm_runtime_enable(phy-dev);
generic_phy = devm_phy_create(phy-dev, ops, NULL);
if (IS_ERR(generic_phy))
@@ -270,10 +269,13 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy_set_drvdata(generic_phy, phy);
+ pm_runtime_enable(phy-dev);
phy_provider = devm_of_phy_provider_register(phy-dev,
of_phy_simple_xlate);
- if (IS_ERR(phy_provider))
+ if (IS_ERR(phy_provider)) {
+ pm_runtime_disable(phy-dev);
return PTR_ERR(phy_provider);
+ }
phy-wkupclk = devm_clk_get(phy-dev, wkupclk);
if (IS_ERR(phy-wkupclk)) {
@@ -317,6 +319,7 @@ static int omap_usb2_remove(struct platform_device *pdev)
if (!IS_ERR(phy-optclk))
clk_unprepare(phy-optclk);
usb_remove_phy(phy-phy);
+ pm_runtime_disable(phy-dev);
return 0;
}
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
