Re: [RESEND PATCH v1 0/2] Add a property in at24.c
On Mon, Jun 25, 2018 at 11:02 AM, Sakari Ailus wrote: > Hi Alan, > On Mon, Jun 25, 2018 at 03:29:41PM +0800, alanx.chi...@intel.com wrote: Agreed on all Sakari's comments against the series. -- With Best Regards, Andy Shevchenko
Re: Bugfix for Tevii S650
+Cc: Mauro On Mon, May 21, 2018 at 3:01 PM, Light <ligh...@inbox.lv> wrote: > Hi, > > staring with kernel 4.1 the tevii S650 usb box is not working any more, last > working version was 4.0. > > The bug was also reported here > https://www.spinics.net/lists/linux-media/msg121356.html > > I found a solution for it and uploaded a patch to the kernel bugzilla. > > See here: https://bugzilla.kernel.org/show_bug.cgi?id=197731 > > Can somebody of the maintainers have a look on it and apply the patch to the > kernes sources? You forget to Cc to maintainers (at least Mauro). -- With Best Regards, Andy Shevchenko
Re: [PATCH] media: pt1: use #ifdef CONFIG_PM_SLEEP instead of #if
On Sat, May 5, 2018 at 4:24 PM, Mauro Carvalho Chehab
<mchehab+sams...@kernel.org> wrote:
> As pointed by ktest:
>
>>> drivers/media//pci/pt1/pt1.c:1433:5: warning: "CONFIG_PM_SLEEP" is not
>>> defined, evaluates to 0 [-Wundef]
> #if CONFIG_PM_SLEEP
> ^~~
>
Why not to go further and drop this ugly #if(def) in favour of __maybe_unused?
> Reported-by: kbuild test robot <l...@intel.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org>
> ---
> drivers/media/pci/pt1/pt1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/pci/pt1/pt1.c b/drivers/media/pci/pt1/pt1.c
> index 3b7e08a4639a..55a89ea13f2a 100644
> --- a/drivers/media/pci/pt1/pt1.c
> +++ b/drivers/media/pci/pt1/pt1.c
> @@ -1443,7 +1443,7 @@ static struct pci_driver pt1_driver = {
> .probe = pt1_probe,
> .remove = pt1_remove,
> .id_table = pt1_id_table,
> -#if CONFIG_PM_SLEEP
> +#ifdef CONFIG_PM_SLEEP
> .driver.pm = _pm_ops,
> #endif
> };
> --
> 2.17.0
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] media: pt1: fix strncmp() size warning
On Sat, May 5, 2018 at 2:33 PM, Mauro Carvalho Chehab <mchehab+sams...@kernel.org> wrote: > As warned by smatch: > drivers/media/pci/pt1/pt1.c:213 config_demod() error: strncmp() > '"tc90522sat"' too small (11 vs 20) > > Use the same strncmp() syntax as pt1_init_frontends() does. > + is_sat = !strncmp(cl->name, TC90522_I2C_DEV_SAT, > + strlen(TC90522_I2C_DEV_SAT)); In this case I don't see a point to use strNcmp(). Plain strcmp() would work. -- With Best Regards, Andy Shevchenko
Re: [PATCH] media: staging: atomisp: fix a potential missing-check bug
On Fri, 2018-05-04 at 02:29 -0500, Wenwen Wang wrote: > At the end of atomisp_subdev_set_selection(), the function > atomisp_subdev_get_rect() is invoked to get the pointer to v4l2_rect. > Since > this function may return a NULL pointer, it is firstly invoked to > check > the returned pointer. If the returned pointer is not NULL, then the > function is invoked again to obtain the pointer and the memory content > at the location of the returned pointer is copied to the memory > location of > r. In most cases, the pointers returned by the two invocations are > same. > However, given that the pointer returned by the function > atomisp_subdev_get_rect() is not a constant, it is possible that the > two > invocations return two different pointers. For example, another thread > may > race to modify the related pointers during the two invocations. In > that > case, even if the first returned pointer is not null, the second > returned > pointer might be null, which will cause issues such as null pointer > dereference. > > This patch saves the pointer returned by the first invocation and > removes > the second invocation. If the returned pointer is not NULL, the memory > content is copied according to the original code. > The driver will be gone soon, don't bother with it anymore. Thanks! > Signed-off-by: Wenwen Wang <wang6...@umn.edu> > --- > drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c | 6 - > - > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git > a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c > b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c > index 49a9973..d5fa513 100644 > --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c > +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c > @@ -366,6 +366,7 @@ int atomisp_subdev_set_selection(struct > v4l2_subdev *sd, > unsigned int i; > unsigned int padding_w = pad_w; > unsigned int padding_h = pad_h; > + struct v4l2_rect *p; > > stream_id = atomisp_source_pad_to_stream_id(isp_sd, > vdev_pad); > > @@ -536,9 +537,10 @@ int atomisp_subdev_set_selection(struct > v4l2_subdev *sd, > ffmt[pad]->height = comp[pad]->height; > } > > - if (!atomisp_subdev_get_rect(sd, cfg, which, pad, target)) > + p = atomisp_subdev_get_rect(sd, cfg, which, pad, target); > + if (!p) > return -EINVAL; > - *r = *atomisp_subdev_get_rect(sd, cfg, which, pad, target); > + *r = *p; > > dev_dbg(isp->dev, "sel actual: l %d t %d w %d h %d\n", > r->left, r->top, r->width, r->height); -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy
Re: [PATCH 2/7] media: meye: allow building it with COMPILE_TEST on non-x86
On Fri, Apr 20, 2018 at 8:42 PM, Mauro Carvalho Chehab
<mche...@s-opensource.com> wrote:
> This driver depends on sony-laptop driver, but this is available
> only for x86. So, add a stub function, in order to allow building
> it on non-x86 too.
> --- a/include/linux/sony-laptop.h
> +++ b/include/linux/sony-laptop.h
> @@ -28,7 +28,11 @@
> #define SONY_PIC_COMMAND_GETCAMERAROMVERSION 18 /* obsolete */
> #define SONY_PIC_COMMAND_GETCAMERAREVISION 19 /* obsolete */
>
> +#ifdef CONFIG_SONY_LAPTOP
IS_ENABLED(), IS_BUILTIN() ?
> int sony_pic_camera_command(int command, u8 value);
> +#else
> +static inline int sony_pic_camera_command(int command, u8 value) { return 0;
> };
> +#endif
>
> #endif /* __KERNEL__ */
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 07/18] media: staging: atomisp: fix endianess issues
On Mon, 2018-03-26 at 17:10 -0400, Mauro Carvalho Chehab wrote:
> There are lots of be-related warnings there, as it doesn't properly
> mark what data uses bigendian.
> @@ -107,7 +107,7 @@ mt9m114_write_reg(struct i2c_client *client, u16
> data_length, u16 reg, u32 val)
> int num_msg;
> struct i2c_msg msg;
> unsigned char data[6] = {0};
> - u16 *wreg;
> + __be16 *wreg;
>
> + u16 *wdata = (void *)[2];
> +
> + *wdata = be16_to_cpu(*(__be16 *)[2]);
> + u32 *wdata = (void *)[2];
> +
> + *wdata = be32_to_cpu(*(__be32 *)[2]);
For x86 it is okay, though in general it should use get_unaligned().
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
Re: Webcams not recognized on a Dell Latitude 5285 laptop
On Sun, Mar 11, 2018 at 2:38 PM, FRÉDÉRIC PARRENIN <frederic.parre...@univ-grenoble-alpes.fr> wrote: > Dear Oliver and all, > > So I was expecting linux-4.16 to recognize my webcams, thanks to this new PCI > driver Oliver mentioned. > Therefore I installed 4.16-rc4. > Unfortunately, there is still no /dev/video* device > > Any idea what could be done to have these webcams working? I guess you need a driver. Cc: + Sakari, and thus leaving the complete message uncut. > > Thanks, > > Frederic > > >> De: "FRÉDÉRIC PARRENIN" <frederic.parre...@univ-grenoble-alpes.fr> >> À: "Oliver Neukum" <oneu...@suse.com> >> Cc: "linux-usb" <linux-...@vger.kernel.org> >> Envoyé: Lundi 11 Décembre 2017 16:39:41 >> Objet: Re: Webcams not recognized on a Dell Latitude 5285 laptop > >> > > > it looks like you need the experimental driver posted here > >> > > > https://www.spinics.net/lists/linux-media/msg123268.html > >> > > Thanks for the information. >> >> So, if I understand correctly, this driver will not be included in 4.15, >> >> will >> > > it? >> > > Any idea when this will be included in a release? > >> > I have no idea. Could you contact the original developers? >> > The answer is interesting, but I have no idea. > >> It seems it will be included in the 4.16 release: > >> https://www.mail-archive.com/linux-media@vger.kernel.org/msg122619.html > >> Probably just a bit too late for 4.15. > >> Frederic > > !!! WARNING!!! New email address: frederic.parre...@univ-grenoble-alpes.fr > http://pp.ige-grenoble.fr/pageperso/parrenif/index.html > > - Mail original - >> De: "FRÉDÉRIC PARRENIN" <frederic.parre...@univ-grenoble-alpes.fr> >> À: "Oliver Neukum" <oneu...@suse.com> >> Cc: "linux-usb" <linux-...@vger.kernel.org> >> Envoyé: Lundi 11 Décembre 2017 16:39:41 >> Objet: Re: Webcams not recognized on a Dell Latitude 5285 laptop > >> > > > it looks like you need the experimental driver posted here > >> > > > https://www.spinics.net/lists/linux-media/msg123268.html > >> > > Thanks for the information. >> >> So, if I understand correctly, this driver will not be included in 4.15, >> >> will >> > > it? >> > > Any idea when this will be included in a release? > >> > I have no idea. Could you contact the original developers? >> > The answer is interesting, but I have no idea. > >> It seems it will be included in the 4.16 release: > >> https://www.mail-archive.com/linux-media@vger.kernel.org/msg122619.html > >> Probably just a bit too late for 4.15. > >> Frederic > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- With Best Regards, Andy Shevchenko
Re: [PATCH v3 06/10] pwm: add PWM modes
On Thu, Feb 22, 2018 at 2:01 PM, Claudiu Beznea <claudiu.bez...@microchip.com> wrote: > Add PWM normal and complementary modes. > +- PWM_DTMODE_COMPLEMENTARY: PWM complementary working mode (for PWM > +channels two outputs); if not specified, the default for PWM channel will > +be used What DT stands for? -- With Best Regards, Andy Shevchenko
Re: [PATCH 2/5] auxdisplay: charlcd: add flush function
On Mon, Feb 12, 2018 at 10:44 PM, Miguel Ojeda <miguel.ojeda.sando...@gmail.com> wrote: > On Mon, Jan 15, 2018 at 10:58 AM, Sean Young <s...@mess.org> wrote: >> The Sasem Remote Controller has an LCD, which is connnected via usb. >> Multiple write reg or write data commands can be combined into one usb >> packet. >> >> The latency of usb is such that if we send commands one by one, we get >> very obvious tearing on the LCD. >> >> By adding a flush function, we can buffer all commands until either >> the usb packet is full or the lcd changes are complete. > Cc'ing Arnd and Greg since this touches include/misc as well. >> --- a/include/misc/charlcd.h >> +++ b/include/misc/charlcd.h As far as I can see better to create a subfolder under include for auxdisplay stuff. Currently we have three candidates here: linux/cfag12864b.h linux/ks0108.h misc/charlcd.h Another possibility to get rid of them under include/ by (re)moving to drivers/auxdisplay/. -- With Best Regards, Andy Shevchenko
Re: [PATCH] staging: media: atomisp2: remove unused headers
On Mon, Jan 29, 2018 at 3:11 PM, Corentin Labbe <cla...@baylibre.com> wrote: > All thoses headers are not used by any source files. > Lets just remove them. How did you test this? P.S. I like the patch, but since driver in a state of coma vigil, I'm afraid you may do something which shouldn't be done for working driver. -- With Best Regards, Andy Shevchenko
Re: [PATCH v2] staging: media: remove remains of VIDEO_ATOMISP_OV8858
On Mon, 2018-01-29 at 12:16 +, Corentin Labbe wrote:
> OV8858 files are left unusable since commit 3a81c7660f80 ("media:
> staging: atomisp: Remove IMX sensor support")
> They are uncompilable since they depends on dw9718.c and vcm.c which
> was removed.
>
> Remove the OV8858 kconfig and files.
Fine with me. We can sort things out later (repository will have the
sources still in any case) when the driver itself shows signs of life.
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
Re: [PATCH] staging: media: remove unused VIDEO_ATOMISP_OV8858 kconfig
On Fri, Jan 26, 2018 at 2:49 PM, LABBE Corentin <cla...@baylibre.com> wrote:
> On Tue, Jan 23, 2018 at 07:20:12PM +0100, Greg Kroah-Hartman wrote:
>> On Tue, Jan 23, 2018 at 07:31:27PM +0200, Andy Shevchenko wrote:
>> > On Tue, Jan 23, 2018 at 4:37 PM, Corentin Labbe <cla...@baylibre.com>
>> > wrote:
>> > > Nothing in kernel use VIDEO_ATOMISP_OV8858 since commit 3a81c7660f80
>> > > ("media: staging: atomisp: Remove IMX sensor support")
>> > > Lets remove this kconfig option.
>> >
>> > First of all, I hardly understand how that change is related.
>> > Second, did you check Makefile?
>>
>> I don't see it being used in any Makefile, what file do you see it:
>> $ git grep VIDEO_ATOMISP_OV8858
>> drivers/staging/media/atomisp/i2c/Kconfig:config VIDEO_ATOMISP_OV8858
>>
>> So it should be removed.
>>
>> thanks,
> I just see that 3a81c7660f80 left ov8858.c so do you agree that I send a v2
> which remove also this file ?
> av8858.c is useless without dw9718.c and vcm.c which 3a81c7660f80 removed.
Removal of dead code is pretty fine to me, though the decision is to
Alan and Sakari.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] staging: media: remove unused VIDEO_ATOMISP_OV8858 kconfig
On Tue, Jan 23, 2018 at 4:37 PM, Corentin Labbe <cla...@baylibre.com> wrote:
> Nothing in kernel use VIDEO_ATOMISP_OV8858 since commit 3a81c7660f80 ("media:
> staging: atomisp: Remove IMX sensor support")
> Lets remove this kconfig option.
First of all, I hardly understand how that change is related.
Second, did you check Makefile?
Third, the files are in the folder (for OV8858).
Taking all above into account, it seems NACK, though regression might
be made by renaming patch from Sakari (no, it's not).
So, it looks like it was never enabled in the first place.
Anyway, do you have hardware to test? This is *most* important reason
why to accept or decline a change to the driver.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 3/4] tsi108_eth: use dma API properly
On Wed, Jan 10, 2018 at 8:03 PM, Christoph Hellwig <h...@lst.de> wrote:
> We need to pass a struct device to the dma API, even if some
> architectures still support that for legacy reasons, and should not mix
> it with the old PCI dma API.
>
> Note that the driver also seems to never actually unmap its dma mappings,
> but to fix that we'll need someone more familar with the driver.
> + struct platform_device *pdev;
Do you really need platform_defice reference?
Perhaps
struct device *hdev; // hardware device
data->hdev = >dev;
Another idea
dev->dev.parent = >dev;
No new member needed.
> };
>
> /* Structure for a device driver */
> @@ -703,17 +705,18 @@ static int tsi108_send_packet(struct sk_buff * skb,
> struct net_device *dev)
> data->txskbs[tx] = skb;
>
> if (i == 0) {
> - data->txring[tx].buf0 = dma_map_single(NULL,
> skb->data,
> - skb_headlen(skb), DMA_TO_DEVICE);
> + data->txring[tx].buf0 =
> dma_map_single(>pdev->dev,
> + skb->data, skb_headlen(skb),
> + DMA_TO_DEVICE);
> data->txring[tx].len = skb_headlen(skb);
> misc |= TSI108_TX_SOF;
> } else {
> const skb_frag_t *frag = _shinfo(skb)->frags[i -
> 1];
>
> - data->txring[tx].buf0 = skb_frag_dma_map(NULL, frag,
> -0,
> -
> skb_frag_size(frag),
> -
> DMA_TO_DEVICE);
> + data->txring[tx].buf0 =
> + skb_frag_dma_map(>pdev->dev, frag,
> + 0, skb_frag_size(frag),
> + DMA_TO_DEVICE);
> data->txring[tx].len = skb_frag_size(frag);
> }
>
> @@ -808,9 +811,9 @@ static int tsi108_refill_rx(struct net_device *dev, int
> budget)
> if (!skb)
> break;
>
> - data->rxring[rx].buf0 = dma_map_single(NULL, skb->data,
> - TSI108_RX_SKB_SIZE,
> - DMA_FROM_DEVICE);
> + data->rxring[rx].buf0 = dma_map_single(>pdev->dev,
> + skb->data, TSI108_RX_SKB_SIZE,
> + DMA_FROM_DEVICE);
>
> /* Sometimes the hardware sets blen to zero after packet
> * reception, even though the manual says that it's only ever
> @@ -1308,15 +1311,15 @@ static int tsi108_open(struct net_device *dev)
>data->id, dev->irq, dev->name);
> }
>
> - data->rxring = dma_zalloc_coherent(NULL, rxring_size, >rxdma,
> - GFP_KERNEL);
> + data->rxring = dma_zalloc_coherent(>pdev->dev, rxring_size,
> + >rxdma, GFP_KERNEL);
> if (!data->rxring)
> return -ENOMEM;
>
> - data->txring = dma_zalloc_coherent(NULL, txring_size, >txdma,
> - GFP_KERNEL);
> + data->txring = dma_zalloc_coherent(>pdev->dev, txring_size,
> + >txdma, GFP_KERNEL);
> if (!data->txring) {
> - pci_free_consistent(NULL, rxring_size, data->rxring,
> + dma_free_coherent(>pdev->dev, rxring_size, data->rxring,
> data->rxdma);
> return -ENOMEM;
> }
> @@ -1428,10 +1431,10 @@ static int tsi108_close(struct net_device *dev)
> dev_kfree_skb(skb);
> }
>
> - dma_free_coherent(0,
> + dma_free_coherent(>pdev->dev,
> TSI108_RXRING_LEN * sizeof(rx_desc),
> data->rxring, data->rxdma);
> - dma_free_coherent(0,
> + dma_free_coherent(>pdev->dev,
> TSI108_TXRING_LEN * sizeof(tx_desc),
> data->txring, data->txdma);
>
> @@ -1576,6 +1579,7 @@ tsi108_init_one(struct platform_device *pdev)
> printk("tsi108_eth%d: probe...\n", pdev->id);
> data = netdev_priv(dev);
> data->dev = dev;
> + data->pdev = pdev;
>
>
> pr_debug("tsi108_eth%d:regs:phyresgs:phy:irq_num=0x%x:0x%x:0x%x:0x%x\n",
> pdev->id, einfo->regs, einfo->phyregs,
> --
> 2.14.2
>
--
With Best Regards,
Andy Shevchenko
Re: [BUG] atomisp_ov2680 not initializing correctly
On Sat, 2017-12-30 at 20:57 +, Alan Cox wrote: > On Tue, 19 Dec 2017 22:37:01 +0200 > Andy Shevchenko <andriy.shevche...@linux.intel.com> wrote: > > On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote: > > > > I am trying to get the cameras in a Lenovo IdeaPad Miix 320 > > > > (Atom > > > > x5-Z8350 BayTrail) to work. The front camera is an ov2680. With > > > > kernel > > > > 4.14.4 and 4.15rc3 I see the following dmesg output: > > > > It seems I forgot to send the rest of the patches I did while ago > > against AtomISP code. > > > > It includes switch to normal DMI matching instead of the crap we > > have > > there right now. > > The current code expects to be booted on an Android (or ex Android) > tablet. In which case the various values are buried in the EFI as > you'd > expect. Yes, the logic is left untouched, the code has been cleaned up and allow to use more natural DMI matching table. > > WRT to the messages below it seems we have no platform data for that > > device. It needs to be added. > > Or we need to learn how to parse the ACPI data - except that at least > on > some devices the ACPI data is at least half fictional so it's not > clear > what the Windows driver really does. ...if we have any specs inside how that ACPI table was being populated. > > Version string: irci_stable_candrpv_0415_20150423_1753 > > SHA1: 548d26a9b5daedbeb59a46ea1da69757d92cd4d6 shisp_2400b0_v21.bin > > I'll send you a copy: (unfortunately for non Intel people I've not > managed to get enough people to care about this to get permission to > put > the firmware in the public repository ... yet.) I've tried firmware with a version that matches the driver, still same result. I got only "statistics" IRQs (0x20 by value) $ head -z -n1 shisp_2400b0_v21.bin irci_stable_candrpv_0415_20150521_0458 $ sha1sum shisp_2400b0_v21.bin 358d7cd31b2e35b6f812c5bdfc0bc28cc23ce674 shisp_2400b0_v21.bin -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy
Re: [BUG] atomisp_ov2680 not initializing correctly
On Sat, 2017-12-30 at 21:10 +, Alan Cox wrote: > > AFAIR Alan has CHT hardware he is developing / testing on. > > I have a loaned board from the company Vincent (who did the intial > patches) works for. At the moment it's loading firmware, finding > cameras > doing power management but not transferring images. > > Unfortunately because of the design of the driver and firmware at the > moment we are reduced to analyzing all the structs by hand between > multiple different driver releases, and playing games to try and find > out > why various things are not matching up (assuming the firmware we have > will actually work with the Windows tablet in question in the first > place). Maybe we need start over, i.e. find a (presumable old) kernel with driver _and_ corresponding firmware _and_ hardware it supports to start with... > It's nasty because there are complex structs shared between the > firmware > and the OS, and in at least one spot the supposedly 'pristine' CHT > driver > that was used for the merge we now know could never have worked > because > it mismatched its own firmware ! Argh! > On BYT I can't currently do much as my latest Intel Android tablet has > died and it's getting hard to find more because I guess the rest of > those > made have also died. I have MRD7 with some BIOS on it I even don't know if there is any newer still available inside. -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy
Re: [BUG] atomisp_ov2680 not initializing correctly
On Tue, 2018-01-02 at 18:31 +, Alan Cox wrote: > > Patch 0003-atomisp_gmin_platform-tweak-to-drive-axp288.patch gives a > > little confusion. > > The PMIC driver should work via ACPI OpRegion macro (and should be > > enabled in kernel configuration). That's how it supposed to work. > > The patch seems redundant. > > I am fairly sure it is meant to work that way - but it doesn't. At > least > not at the moment. Hmm... At least I see writes to PMIC on my side through OpRegion driver. (Assuming my ugly hack patches applied) > > > I see your point, Still it feels, as if this could go somewhere. > > > > I hope so, though I didn't try CherryTrail and according to Alan > > that > > is what he had tried on. > > It's what we are currently trying on. I can fire up the ISP and > actually > get interrupts from it, but not much more at this point. Seems you are ahead of everyone who is trying AtomISP till now. -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy
Re: [BUG] atomisp_ov2680 not initializing correctly
On Sun, Dec 31, 2017 at 5:19 PM, Kristian Beilke <bei...@posteo.de> wrote:
> On 12/28/2017 05:03 PM, Andy Shevchenko wrote:
>> On Sat, 2017-12-23 at 01:31 +0100, Kristian Beilke wrote:
>>> On 12/21/2017 03:23 PM, Andy Shevchenko wrote:
>>>> On Thu, 2017-12-21 at 13:54 +0100, Kristian Beilke wrote:
>>>>> On Tue, Dec 19, 2017 at 10:37:01PM +0200, Andy Shevchenko wrote:
>>>>>> On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote:
>>>>>>> Cc Alan and Andy.
>>>>>>>
>>>>>>> On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke
>>>>>>> wrote:
>>>>>>>> Dear all,
>>>>>>>>
>>>>>>>> I am trying to get the cameras in a Lenovo IdeaPad Miix 320
>>>>>>>> (Atom
>>>>>>>> x5-Z8350 BayTrail) to work. The front camera is an ov2680.
>>>>>>>> With
>>>
>>> CherryTrail
>
>>>>>> WRT to the messages below it seems we have no platform data for
>>>>>> that
>>>>>> device. It needs to be added.
>>>>>>
>>>
>>> I tried to do exactly this. Extracted some values from
>>> acpidump/acpixtract and dmidecode, but unsure I nailed it.
>>
>> Can you share somewhere it (pastebin.com, gist.github.com, etc)?
>>
>
> https://gist.github.com/jdkbx/dabe0d000330dd2a04acf8d870e0e06f
>
> dmidecode gives me
>
> Handle 0x0002, DMI type 2, 17 bytes
> Base Board Information
> Manufacturer: LENOVO
> Product Name: LNVNB161216
> Version: SDK0J91196WIN
>
> what I assume works as identifier in:
> DMI_MATCH(DMI_BOARD_NAME, "LNVNB161216")
>
> diff --git
> a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> index 87216bc35648..716be4ace60e 100644
> ---
> a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> +++
> b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> @@ -503,6 +503,18 @@ static struct gmin_cfg_var cht_cr_vars[] = {
> {},
> };
>
> +static struct gmin_cfg_var miix320_vars[] = {
> +{"OVTI2680:00_CamType", "1"},
> +{"OVTI2680:00_CsiPort", "0"},
> +{"OVTI2680:00_CsiLanes", "1"},
> +{"OVTI2680:00_CsiFmt", "15"},
> +{"OVTI2680:00_CsiBayer", "0"},
> +{"OVTI2680:00_CamClk", "1"},
> +{"OVTI2680:00_Regulator1p8v", "0"},
> +{"OVTI2680:00_Regulator2p8v", "0"},
> +{},
> +};
> +
> static struct gmin_cfg_var mrd7_vars[] = {
> {"INT33F8:00_CamType", "1"},
> {"INT33F8:00_CsiPort", "1"},
> @@ -566,6 +578,13 @@ static const struct dmi_system_id gmin_vars[] = {
> },
> .driver_data = cht_cr_vars,
> },
> + {
> +.ident = "MIIX320",
> +.matches = {
> +DMI_MATCH(DMI_BOARD_NAME, "LNVNB161216"),
> +},
> +.driver_data = miix320_vars,
> +},
> {
> .ident = "MRD7",
> .matches = {
>
>>> After your set of patches I applied the CherryTrail support I found
>>> here
>>> https://github.com/croutor/atomisp2401
Hmm... Missed this URL.
Patch 0003-atomisp_gmin_platform-tweak-to-drive-axp288.patch gives a
little confusion.
The PMIC driver should work via ACPI OpRegion macro (and should be
enabled in kernel configuration). That's how it supposed to work.
The patch seems redundant.
Anyway, nice finding, I guess we need to include Vincent to this discussion.
>> Second, apply
>> Third, you need to change pmic_id to be PMIC_AXP (I have longer patch
>> for this, that's why don't post here). Just hard code it for now in gmin
>> file.
> I assume the given patch set does already what you suggest here, apart
> from the DDEBUG DEFINE.
No, those are completely ugly hacks to prevent driver fail on probing.
>> Fourth, you have to be sure the clock rate is chosen correctly
>> (currently there is a bug in clk_set_rate() where parameter is clock
>> source index instead of frequency!). I think you need to hardcode
>> 1920 there instead of gs->clock_src.
>
> I found nothing about this in the patch set, so I will do this manually.
Yep, there is none in the wild to address this issue.
>> You are expecting /dev/video nodes. /dev/camera is usually a udev's
>> alias against one of /dev/video nodes.
>
> As described by Alan in a later mail, this actually gives me 10
> /dev/video[0-10] nodes, but none producing any images. video4 and
> video10 cause a kernel oops when opened.
The most interesting one is /dev/video0 (capture, i.e. photo).
>>> Am I on the right track here, or am
>>> I wasting my (and your) time?
>> It's both: track is right and it's waste of time.
> I see your point, Still it feels, as if this could go somewhere.
I hope so, though I didn't try CherryTrail and according to Alan that
is what he had tried on.
> Anyway,
> thanks for your explanations and the time you invested into this.
You are welcome!
--
With Best Regards,
Andy Shevchenko
Re: [BUG] atomisp_ov2680 not initializing correctly
+Cc Hans. On Thu, 2017-12-28 at 18:03 +0200, Andy Shevchenko wrote: > On Sat, 2017-12-23 at 01:31 +0100, Kristian Beilke wrote: > > On 12/21/2017 03:23 PM, Andy Shevchenko wrote: I spend more time on investigating some additional stuff Sakari gave me, but no result so far. So, the verbose debug output is here: https://pastebin.com/RUV8gsUJ Can anyone tell what's going on? Note the idle state between 803s - 806s. I pressed Ctrl+C there since no expected IRQ came. So, was it ever tested on Baytrail??? Who can debug this properly? For now it's a quite waste of time. I doubt I want to do anything anymore for this. Consider I'm in postponed state until there will be a *proven* way to test it. Otherwise, I'm voting 10x times to remove this driver from upstream for good. P.S. Happy New Year, everyone! -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy
Re: IRQ behaivour has been changed from v4.14 to v4.15-rc1
On Fri, 2017-12-29 at 14:10 +0100, Thomas Gleixner wrote:
> On Fri, 29 Dec 2017, Andy Shevchenko wrote:
>
> > On Thu, 2017-12-28 at 22:59 +0100, Thomas Gleixner wrote:
> > > On Thu, 28 Dec 2017, Thomas Gleixner wrote:
> > > > On Thu, 28 Dec 2017, Andy Shevchenko wrote:
> > > > > The result w/o above is (full log is available here
> > > > > https://pastebin.com
> > > > > /J5yaTbM9):
> > > >
> > > > Ok. Which irqs are related to that ISP thingy?
> > > >
> > > > Are these interrupts MSI?
> >
> > Yes, they are MSI.
> >
> > > And looking at the log, I see that you can load the driver
> > > successfully and
> > > the trouble starts afterwards when you actually use it.
> >
> > Correct.
> >
> > > Can you please enable CONFIG_GENERIC_IRQ_DEBUGFS and after login,
> > > check
> > > which interrupt is assigned to that atomisp thingy and then
> > > provide
> > > the
> > > output of
> > >
> > > cat /sys/kernel/debug/irq/irqs/$ATOMISPIRQ
> >
> > Full log, including output of the above.
> >
> > https://pastebin.com/4jammqi5
>
> Thanks for the info. Can you please test the patch below?
Thanks for the patch. It does a trick!
P.S. I noticed that it's combined from at least one that is already in
x86/urgent, so, feel free to add my
Reported-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
Tested-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
to the rest
>
> Thanks,
>
> tglx
>
> 8<
> --- a/kernel/irq/msi.c
> +++ b/kernel/irq/msi.c
> @@ -339,6 +339,40 @@ int msi_domain_populate_irqs(struct irq_
> return ret;
> }
>
> +/*
> + * Carefully check whether the device can use reservation mode. If
> + * reservation mode is enabled then the early activation will assign
> a
> + * dummy vector to the device. If the PCI/MSI device does not support
> + * masking of the entry then this can result in spurious interrupts
> when
> + * the device driver is not absolutely careful. But even then a
> malfunction
> + * of the hardware could result in a spurious interrupt on the dummy
> vector
> + * and render the device unusable. If the entry can be masked then
> the core
> + * logic will prevent the spurious interrupt and reservation mode can
> be
> + * used. For now reservation mode is restricted to PCI/MSI.
> + */
> +static bool msi_check_reservation_mode(struct irq_domain *domain,
> +struct msi_domain_info *info,
> +struct device *dev)
> +{
> + struct msi_desc *desc;
> +
> + if (domain->bus_token != DOMAIN_BUS_PCI_MSI)
> + return false;
> +
> + if (!(info->flags & MSI_FLAG_MUST_REACTIVATE))
> + return false;
> +
> + if (IS_ENABLED(CONFIG_PCI_MSI) && pci_msi_ignore_mask)
> + return false;
> +
> + /*
> + * Checking the first MSI descriptor is sufficient. MSIX
> supports
> + * masking and MSI does so when the maskbit is set.
> + */
> + desc = first_msi_entry(dev);
> + return desc->msi_attrib.is_msix || desc->msi_attrib.maskbit;
> +}
> +
> /**
> * msi_domain_alloc_irqs - Allocate interrupts from a MSI interrupt
> domain
> * @domain: The domain to allocate from
> @@ -353,9 +387,11 @@ int msi_domain_alloc_irqs(struct irq_dom
> {
> struct msi_domain_info *info = domain->host_data;
> struct msi_domain_ops *ops = info->ops;
> - msi_alloc_info_t arg;
> + struct irq_data *irq_data;
> struct msi_desc *desc;
> + msi_alloc_info_t arg;
> int i, ret, virq;
> + bool can_reserve;
>
> ret = msi_domain_prepare_irqs(domain, dev, nvec, );
> if (ret)
> @@ -385,6 +421,8 @@ int msi_domain_alloc_irqs(struct irq_dom
> if (ops->msi_finish)
> ops->msi_finish(, 0);
>
> + can_reserve = msi_check_reservation_mode(domain, info, dev);
> +
> for_each_msi_entry(desc, dev) {
> virq = desc->irq;
> if (desc->nvec_used == 1)
> @@ -397,17 +435,28 @@ int msi_domain_alloc_irqs(struct irq_dom
>* the MSI entries before the PCI layer enables MSI
> in the
>* card. Otherwise the card latches a random msi
> message.
>*/
> - if (info->flags & MSI_FLAG_ACTIVATE_EARLY) {
> - struct irq_data *irq_data;
> + if (!(info->flags & MSI_FLAG_ACTIVA
Re: IRQ behaivour has been changed from v4.14 to v4.15-rc1
On Thu, 2017-12-28 at 22:59 +0100, Thomas Gleixner wrote: > On Thu, 28 Dec 2017, Thomas Gleixner wrote: > > On Thu, 28 Dec 2017, Andy Shevchenko wrote: > > > The result w/o above is (full log is available here > > > https://pastebin.com > > > /J5yaTbM9): > > > > Ok. Which irqs are related to that ISP thingy? > > > > Are these interrupts MSI? Yes, they are MSI. > And looking at the log, I see that you can load the driver > successfully and > the trouble starts afterwards when you actually use it. Correct. > Can you please enable CONFIG_GENERIC_IRQ_DEBUGFS and after login, > check > which interrupt is assigned to that atomisp thingy and then provide > the > output of > > cat /sys/kernel/debug/irq/irqs/$ATOMISPIRQ Full log, including output of the above. https://pastebin.com/4jammqi5 -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy
Re: IRQ behaivour has been changed from v4.14 to v4.15-rc1
On Thu, 2017-12-28 at 21:18 +0100, Thomas Gleixner wrote: > On Thu, 28 Dec 2017, Andy Shevchenko wrote: > > On Thu, 2017-12-28 at 18:44 +0100, Thomas Gleixner wrote: > > > On Thu, 28 Dec 2017, Andy Shevchenko wrote: > > > > On Thu, 2017-12-28 at 18:21 +0100, Thomas Gleixner wrote: > > > > > > [ 85.167061] spurious APIC interrupt through vector ff on > > > > > > CPU#0, > > > > > > should never happen. > > > > > > [ 85.199886] atomisp-isp2 :00:03.0: stream[0] started. > > > > > > > > > > > > and Ctrl+C does NOT work. Machine just hangs. > > > > > > > > > > > > It might be related to this: > > > > > > https://lkml.org/lkml/2017/12/22/697 > > > > > > > > > > I don't think so. > > > > > > > > > > Does the patch below cure it? > > > > > > > > Unfortunately, no. > > > > > > > > Same behaviour. > > > > > > > > Tell me if I need to provide some debug before it hangs. For now > > > > I > > > > have > > > > apic=debug (AFAIR it doesn't affect this). > > > > > > The interesting question is why that spurious APIC interrupt > > > through > > > vector > > > ff happens. Can you please add the following to the kernel command > > > line: > > > > > > 'trace_events=irq_vectors:* ftrace_dump_on_oops' > > > > > > and apply the patch below. That should spill out the trace over > > > serial > > > (I > > > hope you have that ...) > > > > With or without CONFIG_FUNCTION_TRACER=y I have got > > > > > > [ 28.977918] Dumping ftrace buffer: > > [ 28.988115](ftrace buffer empty) > > > > followed by BUG() output. > > > > ... > > [ 28.930154] RIP: 0010:smp_spurious_interrupt+0x67/0xb0 > > ... > > > > > > Anything I missed? > > Yes, you missed the typo in the command line. It should be: > > 'trace_event=irq_vectors:* ftrace_dump_on_oops' Indeed. So, I had to disable LOCAL_TIMER_VECTOR, CALL_FUNCTION_VECTOR and RESCHDULE_VECTOR tracing, otherwise I got a lot of spam and RCU stalls. The result w/o above is (full log is available here https://pastebin.com /J5yaTbM9): [ 38.570130] -0 0d...0us : vector_clear: irq=1 vector=49 cpu=0 prev_vector=0 prev_cpu=0 [ 38.606969] -0 0d...0us : vector_reserve: irq=1 ret=0 [ 38.627799] -0 0d...0us : vector_config: irq=1 vector=239 cpu=0 apicdest=0x0001 [ 38.665139] -0 00us : vector_setup: irq=1 is_legacy=0 ret=0 [ 38.687383] -0 0d...0us : vector_setup: irq=0 is_legacy=1 ret=0 [ 38.709354] -0 0d...0us : vector_config: irq=0 vector=48 cpu=0 apicdest=0x0001 [ 38.746192] -0 0d...0us : vector_clear: irq=3 vector=51 cpu=0 prev_vector=0 prev_cpu=0 [ 38.783535] -0 0d...0us : vector_reserve: irq=3 ret=0 [ 38.804574] -0 0d...0us : vector_config: irq=3 vector=239 cpu=0 apicdest=0x0001 [ 38.842397] -0 00us : vector_setup: irq=3 is_legacy=0 ret=0 ... so on up to [ 40.329523] -0 0d...0us : vector_clear: irq=15 vector=63 cpu=0 prev_vector=0 prev_cpu=0 [ 40.372425] -0 0d...0us : vector_reserve: irq=15 ret=0 [ 40.396045] -0 0d...0us : vector_config: irq=15 vector=239 cpu=0 apicdest=0x0001 [ 40.438357] -0 00us : vector_setup: irq=15 is_legacy=0 ret=0 [ 40.463002] -0 0d...0us : vector_deactivate: irq=0 is_managed=0 can_reserve=0 early=0 [ 40.505473] -0 0d...0us : vector_activate: irq=0 is_managed=0 can_reserve=0 early=0 Then several times (for different tasks) [ 40.548017] kauditd-32 0d.h. 307277us : call_function_single_entry: vector=251 [ 40.572984] kauditd-32 0dNh. 307281us : call_function_single_exit: vector=251 ... [ 40.792078] swapper/-1 0d... 390605us : vector_activate: irq=9 is_managed=0 can_reserve=1 early=0 [ 40.832953] swapper/-1 0d... 390611us : vector_update: irq=9 vector=33 cpu=0 prev_vector=0 prev_cpu=0 [ 40.874548] swapper/-1 0d... 390613us : vector_alloc: irq=9 vector=33 reserved=1 ret=0 [ 40.899551] swapper/-1 0d... 390614us : vector_config: irq=9 vector=33 cpu=0 apicdest=0x0001 [ 40.940771] swapper/-1 0d... 390620us : vector_config: irq=9 vector=33 cpu=0 apicdest=0x0001 ... For irq=24-29, 47, 49: [ 41.071806] swapper/-1 1d... 989092us : vector_reserve: irq=24 ret=0 [ 41.088297] swapper/-1 1d... 989096us : vector_config: irq=24 vector=2
Re: IRQ behaivour has been changed from v4.14 to v4.15-rc1
On Thu, 2017-12-28 at 21:31 +0200, Andy Shevchenko wrote: > Anything I missed? Perhaps I could bisect, though it's not so trivial in this case, when I have a little more time. I guess it might take up to ~16 steps. If you can point to more narrow range, it would be great. -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy
Re: IRQ behaivour has been changed from v4.14 to v4.15-rc1
On Thu, 2017-12-28 at 18:44 +0100, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Andy Shevchenko wrote:
> > On Thu, 2017-12-28 at 18:21 +0100, Thomas Gleixner wrote:
> > > > [ 85.167061] spurious APIC interrupt through vector ff on
> > > > CPU#0,
> > > > should never happen.
> > > > [ 85.199886] atomisp-isp2 :00:03.0: stream[0] started.
> > > >
> > > > and Ctrl+C does NOT work. Machine just hangs.
> > > >
> > > > It might be related to this:
> > > > https://lkml.org/lkml/2017/12/22/697
> > >
> > > I don't think so.
> > >
> > > Does the patch below cure it?
> >
> > Unfortunately, no.
> >
> > Same behaviour.
> >
> > Tell me if I need to provide some debug before it hangs. For now I
> > have
> > apic=debug (AFAIR it doesn't affect this).
>
> The interesting question is why that spurious APIC interrupt through
> vector
> ff happens. Can you please add the following to the kernel command
> line:
>
> 'trace_events=irq_vectors:* ftrace_dump_on_oops'
>
> and apply the patch below. That should spill out the trace over serial
> (I
> hope you have that ...)
With or without CONFIG_FUNCTION_TRACER=y I have got
[ 28.977918] Dumping ftrace buffer:
[ 28.988115](ftrace buffer empty)
followed by BUG() output.
...
[ 28.930154] RIP: 0010:smp_spurious_interrupt+0x67/0xb0
...
Anything I missed?
P.S. I didn't apply your previous patch.
> Thanks,
>
> tglx
>
> 8<---
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -1978,6 +1978,8 @@ void __init register_lapic_address(unsig
> /* see sw-dev-man vol 3, chapter 7.4.13.5 */
> pr_info("spurious APIC interrupt through vector %02x on
> CPU#%d, "
> "should never happen.\n", vector,
> smp_processor_id());
> + tracing_off();
> + BUG();
>
> trace_spurious_apic_exit(vector);
> exiting_irq();
>
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
Re: IRQ behaivour has been changed from v4.14 to v4.15-rc1
On Thu, 2017-12-28 at 18:21 +0100, Thomas Gleixner wrote: > On Thu, 28 Dec 2017, Shevchenko, Andriy wrote: > > > Hi! > > > > Experimenting with AtomISP (yes, code is ugly and MSI handling > > rather > > hackish, though...). > > > > So, with v4.14 base: > > > > [ 33.639224] atomisp-isp2 :00:03.0: Start stream on pad 1 for > > asd0 > > [ 33.652355] atomisp-isp2 :00:03.0: irq:0x20 > > [ 33.662456] atomisp-isp2 :00:03.0: irq:0x20 > > [ 33.698064] atomisp-isp2 :00:03.0: stream[0] started. > > > > Ctrl+C > > > > [ 48.185643] atomisp-isp2 :00:03.0: > [ 48.204641] atomisp-isp2 :00:03.0: release device ATOMISP ISP > > CAPTURE output > > ... > > > > and machine still alive. > > > > > > With v4.15-rc1 base (basically your branch + some my hack patches) > > the > > IR > > Q behaviour changed, i.e. I have got: > > > > > > [ 85.167061] spurious APIC interrupt through vector ff on CPU#0, > > should never happen. > > [ 85.199886] atomisp-isp2 :00:03.0: stream[0] started. > > > > and Ctrl+C does NOT work. Machine just hangs. > > > > It might be related to this: > > https://lkml.org/lkml/2017/12/22/697 > > I don't think so. > > Does the patch below cure it? Unfortunately, no. Same behaviour. Tell me if I need to provide some debug before it hangs. For now I have apic=debug (AFAIR it doesn't affect this). > > Thanks, > > tglx > 8<- > arch/x86/kernel/apic/apic_flat_64.c |2 +- > arch/x86/kernel/apic/probe_32.c |2 +- > arch/x86/kernel/apic/x2apic_cluster.c |2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > --- a/arch/x86/kernel/apic/apic_flat_64.c > +++ b/arch/x86/kernel/apic/apic_flat_64.c > @@ -151,7 +151,7 @@ static struct apic apic_flat __ro_after_ > .apic_id_valid = > default_apic_id_valid, > .apic_id_registered = flat_apic_id_registered, > > - .irq_delivery_mode = dest_LowestPrio, > + .irq_delivery_mode = dest_Fixed, > .irq_dest_mode = 1, /* logical */ > > .disable_esr= 0, > --- a/arch/x86/kernel/apic/probe_32.c > +++ b/arch/x86/kernel/apic/probe_32.c > @@ -105,7 +105,7 @@ static struct apic apic_default __ro_aft > .apic_id_valid = > default_apic_id_valid, > .apic_id_registered = > default_apic_id_registered, > > - .irq_delivery_mode = dest_LowestPrio, > + .irq_delivery_mode = dest_Fixed, > /* logical delivery broadcast to all CPUs: */ > .irq_dest_mode = 1, > > --- a/arch/x86/kernel/apic/x2apic_cluster.c > +++ b/arch/x86/kernel/apic/x2apic_cluster.c > @@ -184,7 +184,7 @@ static struct apic apic_x2apic_cluster _ > .apic_id_valid = x2apic_apic_id_valid, > .apic_id_registered = > x2apic_apic_id_registered, > > - .irq_delivery_mode = dest_LowestPrio, > + .irq_delivery_mode = dest_Fixed, > .irq_dest_mode = 1, /* logical */ > > .disable_esr= 0, > > -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy
Re: IRQ behaivour has been changed from v4.14 to v4.15-rc1
On Thu, 2017-12-28 at 19:17 +0200, Andy Shevchenko wrote: > Hi! > > Experimenting with AtomISP (yes, code is ugly and MSI handling rather > hackish, though...). > > So, with v4.14 base: See additional note below. > > [ 33.639224] atomisp-isp2 :00:03.0: Start stream on pad 1 for > asd0 > [ 33.652355] atomisp-isp2 :00:03.0: irq:0x20 > [ 33.662456] atomisp-isp2 :00:03.0: irq:0x20 > [ 33.698064] atomisp-isp2 :00:03.0: stream[0] started. > > Ctrl+C > > [ 48.185643] atomisp-isp2 :00:03.0: [ 48.204641] atomisp-isp2 :00:03.0: release device ATOMISP ISP > CAPTURE output > ... > > and machine still alive. > > > With v4.15-rc1 base (basically your branch + some my hack patches) Needs a bit of elaboration: a) nothing had been changed WRT AtomISP driver or media stuff, under "your branch" one reads Sakari's media_tree.git/atomisp branch; b) my hack patches has nothing to do with anything except AtomISP itself; c) v4.14 base required media/v4.15-1 tag to be merged as well. > the IRQ behaviour changed, i.e. I have got: > > > [ 85.167061] spurious APIC interrupt through vector ff on CPU#0, > should never happen. > [ 85.199886] atomisp-isp2 :00:03.0: stream[0] started. > > and Ctrl+C does NOT work. Machine just hangs. > > It might be related to this: > https://lkml.org/lkml/2017/12/22/697 > > Any comments, Thomas? > -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy
Re: [ov2722 Error] atomisp: ERROR
On Tue, 2017-10-31 at 16:35 +0200, Andrei Lavreniyuk wrote: > Hi, > > Very long I try to run ov2722 on Acer Aspire SW5-012 / Fendi2 Z3537F > > Kernel 4.13.10 + atomisp from 4.14 and all your corrections for > atomisp > from here Check this [1] thread, please. [1]: https://www.spinics.net/lists/linux-media/msg126250.html > > https://patchwork.linuxtv.org/project/linux-media/list/?submitter=Andy > +Shevchenko=* > <https://patchwork.linuxtv.org/project/linux-media/list/?submitter=And > y+Shevchenko=*> > > as a result: > > [69.677080] media: Linux media interface: v0.10 > [69.699534] Linux video capture interface: v2.00 > [69.714154] ov2722: module is from the staging directory, the quality > is > unknown, you have been warned. > [69.777623] ov2722 i2c-INT33FB: 00: gmin: initializing the atomisp > module subdev data.PMIC ID 1 > [69.778097] ov2722 i2c-INT33FB: 00: i2c-INT33FB: 00 supply V1P8SX not > found, using dummy regulator > [69.778208] ov2722 i2c-INT33FB: 00: i2c-INT33FB: 00 supply V2P8SX not > found, using dummy regulator > [69.778278] ov2722 i2c-INT33FB: 00: i2c-INT33FB: 00 supply V1P2A not > found, using dummy regulator > [69.778348] ov2722 i2c-INT33FB: 00: i2c-INT33FB: 00 supply VPROG4B > not > found, using dummy regulator > [69.785182] ov2722 i2c-INT33FB: 00: unable to set PMC rate 0 > [69.807860] ov2722 i2c-INT33FB: 00: camera pdata: port: 0 lanes: 1 > order: > [69.808183] ov2722 i2c-INT33FB: 00: read from offset 0x300a error -121 > [69.808203] ov2722 i2c-INT33FB: 00: sensor_id_high = 0x > [69.808216] ov2722 i2c-INT33FB: 00: ov2722_detect err s_config. > [69.808259] ov2722 i2c-INT33FB: 00: sensor power-gating failed > > > Tested the kernels from the repositories: > https://github.com/torvalds/linux > <https://github.com/torvalds/linux> and master from git.linuxtv.org > <http://git.linuxtv.org/> > > The result is the same - ov2722 i2c-INT33FB: 00: read from offset > 0x300a error -121 > > Additional information for debug: > https://drive.google.com/drive/folders/0B5ngHZIeNdyTM0FEbWNVQzlpNUU > <https://drive.google.com/drive/folders/0B5ngHZIeNdyTM0FEbWNVQzlpNUU> > > Kernel build form my repo - > https://github.com/AndyLavr/Aspire-SW5-012_Kernel_4.13 > <https://github.com/AndyLavr/Aspire-SW5-012_Kernel_4.13> > > If you need more information, then I will. > > > --- > Best regards, Andrei Lavreniyuk > > -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy
Re: [BUG] atomisp_ov2680 not initializing correctly
On Sat, 2017-12-23 at 01:31 +0100, Kristian Beilke wrote: > On 12/21/2017 03:23 PM, Andy Shevchenko wrote: > > On Thu, 2017-12-21 at 13:54 +0100, Kristian Beilke wrote: > > > On Tue, Dec 19, 2017 at 10:37:01PM +0200, Andy Shevchenko wrote: > > > > On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote: > > > > > Cc Alan and Andy. > > > > > > > > > > On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke > > > > > wrote: > > > > > > Dear all, > > > > > > > > > > > > I am trying to get the cameras in a Lenovo IdeaPad Miix 320 > > > > > > (Atom > > > > > > x5-Z8350 BayTrail) to work. The front camera is an ov2680. > > > > > > With > > CherryTrail I didn't try even find a CherryTrail on hand that have AtomISP enumerated by PCI with a camera sensor connected. AFAIR Alan has CHT hardware he is developing / testing on. > > > > WRT to the messages below it seems we have no platform data for > > > > that > > > > device. It needs to be added. > > > > > > I tried to do exactly this. Extracted some values from > acpidump/acpixtract and dmidecode, but unsure I nailed it. Can you share somewhere it (pastebin.com, gist.github.com, etc)? > > > > > > Can I somehow help to improve > > > > > > the driver? > > > > > > > > Yes, definitely, but first of all we need to find at least one > > > > device > > > > and corresponding firmware where it actually works. > > > > > > > > For me it doesn't generate any interrupt (after huge hacking to > > > > make > > > > that firmware loaded and settings / platform data applied). > > > > > > > > > > What exactly are you looking for? > > > > For anything that *somehow* works. > > > > > An Android device where the ov2680 > > > works? > > > > First of all, I most likely do not have hardware with such sensor. > > Second, I'm using one of the prototype HW based on BayTrail with PCI > > enumerable AtomISP. > > > > > Some x86_64 hardware, where the matching firmware is available > > > and > > > the driver in 4.15 works? > > > > Yes, that's what I would like to have before moving forward with any > > new > > sensor drivers, clean ups or alike type of changes to the driver. > > > > After your set of patches I applied the CherryTrail support I found > here > https://github.com/croutor/atomisp2401 > > As a result I get: > > [0.00] DMI: LENOVO 80XF/LNVNB161216, BIOS 5HCN31WW 09/11/2017 > [2.806685] axp20x-i2c i2c-INT33F4:00: AXP20x variant AXP288 found > [2.849606] axp20x-i2c i2c-INT33F4:00: AXP20X driver loaded > [ 19.593200] media: Linux media interface: v0.10 > [ 19.627138] Linux video capture interface: v2.00 > [ 19.652771] atomisp_ov2680: module is from the staging directory, > the > quality is unknown, you have been warned. > [ 19.676093] ov2680 i2c-OVTI2680:00: gmin: initializing atomisp > module > subdev data.PMIC ID 2 > [ 19.676097] ov2680 i2c-OVTI2680:00: suddev name = ov2680 0-0010 > [ 19.677548] gmin_v1p8_ctrl PMIC_AXP. > [ 19.685261] axp_regulator_set success. > [ 19.685428] axp_v1p8_on XXOV2680 0010 > [ 19.691777] axp_regulator_set success. > [ 19.708488] dw_dmac INTL9C60:00: DesignWare DMA Controller, 8 > channels > [ 19.752432] ov2680 i2c-OVTI2680:00: unable to set PMC rate 1 > [ 19.760507] dw_dmac INTL9C60:01: DesignWare DMA Controller, 8 > channels > [ 19.789335] ov2680 i2c-OVTI2680:00: camera pdata: port: 0 lanes: 1 > order: 0002 > [ 19.793616] ov2680 i2c-OVTI2680:00: sensor_revision id = 0x2680 > [ 19.793638] gmin_v1p8_ctrl PMIC_AXP. > [ 19.802615] axp_regulator_set success. > [ 19.806384] axp_regulator_set success. > [ 19.806396] ov2680 i2c-OVTI2680:00: register atomisp i2c module > type 1 > [ 19.859215] shpchp: Standard Hot Plug PCI Controller Driver > version: 0.4 > [ 19.906592] atomisp: module is from the staging directory, the > quality is unknown, you have been warned. > > [ 19.910763] > ** > [ 19.910765] ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE > NOTICE ** > [ 19.910766] > ** ** > [ 19.910767] ** trace_printk() being used. Allocating extra > memory. ** > [ 19.910768] > ** ** > [ 19.910769] ** This mean
Re: [BUG] atomisp_ov2680 not initializing correctly
On Thu, 2017-12-21 at 13:54 +0100, Kristian Beilke wrote: > On Tue, Dec 19, 2017 at 10:37:01PM +0200, Andy Shevchenko wrote: > > On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote: > > > Cc Alan and Andy. > > > > > > On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke wrote: > > > > Dear all, > > > > > > > > I am trying to get the cameras in a Lenovo IdeaPad Miix 320 > > > > (Atom > > > > x5-Z8350 BayTrail) to work. The front camera is an ov2680. With > > > > kernel > > > > 4.14.4 and 4.15rc3 I see the following dmesg output: > > > > It seems I forgot to send the rest of the patches I did while ago > > against AtomISP code. > > > > It includes switch to normal DMI matching instead of the crap we > > have > > there right now. > > > > WRT to the messages below it seems we have no platform data for that > > device. It needs to be added. > > > > In any case, I have no firmware to test BayTrail hardware I have > > (MRD7). > > > > The driver claims it needs: > > > > Firmware file: shisp_2400b0_v21.bin > > Version string: irci_stable_candrpv_0415_20150521_0458 > > > > What I have is: > > > > Version string: irci_stable_candrpv_0415_20150423_1753 > > SHA1: 548d26a9b5daedbeb59a46ea1da69757d92cd4d6 shisp_2400b0_v21.bin > > > > I am a bit at a loss here. The TODO file says > > 7. The ISP code depends on the exact FW version. The version defined > in >BYT: >drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware. > c >static const char *release_version = > STR(irci_stable_candrpv_0415_20150521_0458); >CHT: >drivers/staging/media/atomisp/pci/atomisp2/css/sh_css_firmware.c >static const char *release_version = STR(irci_ecr- > master_20150911_0724); > > The different files obviously have been merged into the first: > > /* The string STR is a place holder > * which will be replaced with the actual RELEASE_VERSION > * during package generation. Please do not modify */ > #ifndef ISP2401 > static const char *release_version = > STR(irci_stable_candrpv_0415_20150521_0458); > #else > static const char *release_version = STR(irci_ecr- > master_20150911_0724); > #endif > > Trying to find the firmware files I came up with: > > strings shisp_2400b0_v21.bin | grep irci > irci_stable_candrpv_0415_20150423_1753 > > strings shisp_2401a0_v21.bin | grep irci > irci_stable_candrpv_0415_20150521_0458 > > which seems to be an odd match. The CherryTrail FW is older than the > one > expected, but I could not find a newer one. The BayTrail FW is the > same > you have (but it should at least be compatible). > Any hints on where to find the expected FW files? As my hardware is > no android device, I can not look into an update kit. For now we are all using that firmware I mentioned (with, of course, hack-patch applied to make driver swallow it). >>>> Can I somehow help to improve > > > > the driver? > > > > Yes, definitely, but first of all we need to find at least one > > device > > and corresponding firmware where it actually works. > > > > For me it doesn't generate any interrupt (after huge hacking to make > > that firmware loaded and settings / platform data applied). > > > > What exactly are you looking for? For anything that *somehow* works. > An Android device where the ov2680 > works? First of all, I most likely do not have hardware with such sensor. Second, I'm using one of the prototype HW based on BayTrail with PCI enumerable AtomISP. > Some x86_64 hardware, where the matching firmware is available and > the driver in 4.15 works? Yes, that's what I would like to have before moving forward with any new sensor drivers, clean ups or alike type of changes to the driver. -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy
Re: [PATCH v1 05/10] staging: atomisp: Remove non-ACPI leftovers
On Wed, Dec 20, 2017 at 6:54 AM, Dan Carpenter <dan.carpen...@oracle.com> wrote: > On Tue, Dec 19, 2017 at 10:59:52PM +0200, Andy Shevchenko wrote: >> @@ -1147,10 +1145,8 @@ static int gc2235_probe(struct i2c_client *client) >> if (ret) >> gc2235_remove(client); > > This error handling is probably wrong... > Thanks for pointing to this, but I'm not going to fix this by the following reasons: 1. I admit the driver's code is ugly 2. It's staging code 3. My patch does not touch those lines 4. My purpose is to get it working first. Feel free to send a followup with a good clean up which I agree with. >> >> - if (ACPI_HANDLE(>dev)) >> - ret = atomisp_register_i2c_module(>sd, gcpdev, >> RAW_CAMERA); >> + return atomisp_register_i2c_module(>sd, gcpdev, RAW_CAMERA); > > In the end this should look something like: > > ret = atomisp_register_i2c_module(>sd, gcpdev, RAW_CAMERA); > if (ret) > goto err_free_something; > > return 0; > >> >> - return ret; >> out_free: >> v4l2_device_unregister_subdev(>sd); >> kfree(dev); > > regards, > dan carpenter > -- With Best Regards, Andy Shevchenko
[PATCH v1 07/10] staging: atomisp: Remove redundant PCI code
There is no need to keep a reference to PCI root bridge.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h | 1 -
drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 8
2 files changed, 9 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
index 52a6f8002048..dc476a3dd271 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
@@ -227,7 +227,6 @@ struct atomisp_device {
struct media_device media_dev;
struct atomisp_platform_data *pdata;
void *mmu_l1_base;
- struct pci_dev *pci_root;
const struct firmware *firmware;
struct pm_qos_request pm_qos;
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index 7a9efc6847ca..548e00e7d67b 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -1210,11 +1210,6 @@ static int atomisp_pci_probe(struct pci_dev *dev,
isp->pdev = dev;
isp->dev = >dev;
isp->sw_contex.power_state = ATOM_ISP_POWER_UP;
- isp->pci_root = pci_get_bus_and_slot(0, 0);
- if (!isp->pci_root) {
- dev_err(>dev, "Unable to find PCI host\n");
- return -ENODEV;
- }
isp->saved_regs.ispmmadr = start;
rt_mutex_init(>mutex);
@@ -1494,7 +1489,6 @@ static int atomisp_pci_probe(struct pci_dev *dev,
/* Address later when we worry about the ...field chips */
if (IS_ENABLED(CONFIG_PM) && atomisp_mrfld_power_down(isp))
dev_err(>dev, "Failed to switch off ISP\n");
- pci_dev_put(isp->pci_root);
return err;
}
@@ -1515,8 +1509,6 @@ static void atomisp_pci_remove(struct pci_dev *dev)
pm_qos_remove_request(>pm_qos);
atomisp_msi_irq_uninit(isp, dev);
- pci_dev_put(isp->pci_root);
-
atomisp_unregister_entities(isp);
destroy_workqueue(isp->wdt_work_queue);
--
2.15.1
[PATCH v1 01/10] staging: atomisp: Don't leak GPIO resources if clk_get() failed
In case devm_clk_get() call fails the previously requested GPIOs are left requested. Fix this by moving GPIO request code after devm_clk_get() call. Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> --- .../staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c index bf9f34b7ad72..a5d0dd88a8bc 100644 --- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c +++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c @@ -322,8 +322,6 @@ static struct gmin_subdev *gmin_subdev_add(struct v4l2_subdev *subdev) VLV2_CLK_PLL_19P2MHZ); gmin_subdevs[i].csi_port = gmin_get_var_int(dev, "CsiPort", 0); gmin_subdevs[i].csi_lanes = gmin_get_var_int(dev, "CsiLanes", 1); - gmin_subdevs[i].gpio0 = gpiod_get_index(dev, NULL, 0, GPIOD_OUT_LOW); - gmin_subdevs[i].gpio1 = gpiod_get_index(dev, NULL, 1, GPIOD_OUT_LOW); /* get PMC clock with clock framework */ snprintf(gmin_pmc_clk_name, @@ -356,9 +354,11 @@ static struct gmin_subdev *gmin_subdev_add(struct v4l2_subdev *subdev) if (!ret) clk_disable_unprepare(gmin_subdevs[i].pmc_clk); + gmin_subdevs[i].gpio0 = gpiod_get_index(dev, NULL, 0, GPIOD_OUT_LOW); if (IS_ERR(gmin_subdevs[i].gpio0)) gmin_subdevs[i].gpio0 = NULL; + gmin_subdevs[i].gpio1 = gpiod_get_index(dev, NULL, 1, GPIOD_OUT_LOW); if (IS_ERR(gmin_subdevs[i].gpio1)) gmin_subdevs[i].gpio1 = NULL; -- 2.15.1
[PATCH v1 08/10] staging: atomisp: Unexport local function
There is no need to export function which is only used once in
the same module where it's defined.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/staging/media/atomisp/include/linux/atomisp_gmin_platform.h | 1 -
.../staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c | 5 ++---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git
a/drivers/staging/media/atomisp/include/linux/atomisp_gmin_platform.h
b/drivers/staging/media/atomisp/include/linux/atomisp_gmin_platform.h
index 7e3ca12dd4e9..c52c56a17e17 100644
--- a/drivers/staging/media/atomisp/include/linux/atomisp_gmin_platform.h
+++ b/drivers/staging/media/atomisp/include/linux/atomisp_gmin_platform.h
@@ -23,7 +23,6 @@ int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
struct v4l2_subdev *atomisp_gmin_find_subdev(struct i2c_adapter *adapter,
struct i2c_board_info *board_info);
int atomisp_gmin_remove_subdev(struct v4l2_subdev *sd);
-int gmin_get_config_var(struct device *dev, const char *var, char *out, size_t
*out_len);
int gmin_get_var_int(struct device *dev, const char *var, int def);
int camera_sensor_csi(struct v4l2_subdev *sd, u32 port,
u32 lanes, u32 format, u32 bayer_order, int flag);
diff --git
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 8dcec0e780a1..0f859bb714bf 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -608,8 +608,8 @@ EXPORT_SYMBOL_GPL(atomisp_gmin_register_vcm_control);
* argument should be a device with an ACPI companion, as all
* configuration is based on firmware ID.
*/
-int gmin_get_config_var(struct device *dev, const char *var, char *out,
- size_t *out_len)
+static int gmin_get_config_var(struct device *dev, const char *var,
+ char *out, size_t *out_len)
{
char var8[CFG_VAR_NAME_MAX];
efi_char16_t var16[CFG_VAR_NAME_MAX];
@@ -691,7 +691,6 @@ int gmin_get_config_var(struct device *dev, const char
*var, char *out,
return ret;
}
-EXPORT_SYMBOL_GPL(gmin_get_config_var);
int gmin_get_var_int(struct device *dev, const char *var, int def)
{
--
2.15.1
[PATCH v1 09/10] staging: atomisp: Use standard DMI match table
The traditional pattern is to use DMI matching table and provide a
corresponding driver_data in it.
Convert driver to use DMI matching table.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
.../platform/intel-mid/atomisp_gmin_platform.c | 109 +
1 file changed, 70 insertions(+), 39 deletions(-)
diff --git
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 0f859bb714bf..8408a58ed764 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -209,7 +209,7 @@ struct gmin_cfg_var {
const char *name, *val;
};
-static const struct gmin_cfg_var ffrd8_vars[] = {
+static struct gmin_cfg_var ffrd8_vars[] = {
{ "INTCF1B:00_ImxId","0x134" },
{ "INTCF1B:00_CsiPort", "1" },
{ "INTCF1B:00_CsiLanes", "4" },
@@ -220,14 +220,14 @@ static const struct gmin_cfg_var ffrd8_vars[] = {
/* Cribbed from MCG defaults in the mt9m114 driver, not actually verified
* vs. T100 hardware
*/
-static const struct gmin_cfg_var t100_vars[] = {
+static struct gmin_cfg_var t100_vars[] = {
{ "INT33F0:00_CsiPort", "0" },
{ "INT33F0:00_CsiLanes", "1" },
{ "INT33F0:00_CamClk", "1" },
{},
};
-static const struct gmin_cfg_var mrd7_vars[] = {
+static struct gmin_cfg_var mrd7_vars[] = {
{"INT33F8:00_CamType", "1"},
{"INT33F8:00_CsiPort", "1"},
{"INT33F8:00_CsiLanes", "2"},
@@ -243,7 +243,7 @@ static const struct gmin_cfg_var mrd7_vars[] = {
{},
};
-static const struct gmin_cfg_var ecs7_vars[] = {
+static struct gmin_cfg_var ecs7_vars[] = {
{"INT33BE:00_CsiPort", "1"},
{"INT33BE:00_CsiLanes", "2"},
{"INT33BE:00_CsiFmt", "13"},
@@ -258,8 +258,7 @@ static const struct gmin_cfg_var ecs7_vars[] = {
{},
};
-
-static const struct gmin_cfg_var i8880_vars[] = {
+static struct gmin_cfg_var i8880_vars[] = {
{"XXOV2680:00_CsiPort", "1"},
{"XXOV2680:00_CsiLanes", "1"},
{"XXOV2680:00_CamClk", "0"},
@@ -269,18 +268,45 @@ static const struct gmin_cfg_var i8880_vars[] = {
{},
};
-static const struct {
- const char *dmi_board_name;
- const struct gmin_cfg_var *vars;
-} hard_vars[] = {
- { "BYT-T FFD8", ffrd8_vars },
- { "T100TA", t100_vars },
- { "MRD7", mrd7_vars },
- { "ST70408", ecs7_vars },
- { "VTA0803", i8880_vars },
+static const struct dmi_system_id gmin_vars[] = {
+ {
+ .ident = "BYT-T FFD8",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
+ },
+ .driver_data = ffrd8_vars,
+ },
+ {
+ .ident = "T100TA",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "T100TA"),
+ },
+ .driver_data = t100_vars,
+ },
+ {
+ .ident = "MRD7",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "MRD7"),
+ },
+ .driver_data = mrd7_vars,
+ },
+ {
+ .ident = "ST70408",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "ST70408"),
+ },
+ .driver_data = ecs7_vars,
+ },
+ {
+ .ident = "VTA0803",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VTA0803"),
+ },
+ .driver_data = i8880_vars,
+ },
+ {}
};
-
#define GMIN_CFG_VAR_EFI_GUID EFI_GUID(0xecb54cd9, 0xe5ae, 0x4fdc, \
0xa9, 0x71, 0xe8, 0x77, \
0x75, 0x60, 0x68, 0xf7)
@@ -604,6 +630,29 @@ int atomisp_gmin_register_vcm_control(struct
camera_vcm_control *vcmCtrl)
}
EXPORT_SYMBOL_GPL(atomisp_gmin_register_vcm_control);
+static int gmin_get_hardcoded_var(struct gmin_cfg_var *varlist,
+ const char *var8, char *out, size_t *out_len)
+{
+ struct gmin_cfg_var *gv;
+
+ for (gv = varlist; gv->name; gv++) {
+ size_t vl;
+
+ if (strcmp(var8, gv->name))
+ continue;
+
+ vl = strlen(gv->val);
+ if (vl > *out_len - 1)
+ return -ENOSPC;
+
+
[PATCH v1 04/10] staging: atomisp: Disable custom format for now
Custom video format 'M101' is not supported in upstream and as a result
user will get ugly warning:
Unknown pixelformat 0x3130314d
[ cut here ]
WARNING: CPU: 3 PID: 1574 at drivers/media/v4l2-core/v4l2-ioctl.c:1291
v4l_enum_fmt+0xcf1/0x13a0 [videodev]
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/staging/media/atomisp/include/linux/atomisp.h | 2 ++
drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c | 5 -
drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c | 2 ++
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/include/linux/atomisp.h
b/drivers/staging/media/atomisp/include/linux/atomisp.h
index 15fa5679bae7..ebe193ba3871 100644
--- a/drivers/staging/media/atomisp/include/linux/atomisp.h
+++ b/drivers/staging/media/atomisp/include/linux/atomisp.h
@@ -68,7 +68,9 @@
#define V4L2_MBUS_FMT_CUSTOM_RGB32 0x800a
/* Custom media bus format for M10MO RAW capture */
+#if 0
#define V4L2_MBUS_FMT_CUSTOM_M10MO_RAW 0x800b
+#endif
/* Configuration used by Bayer noise reduction and YCC noise reduction */
struct atomisp_nr_config {
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c
index 339b5d31e1f1..5c84dd63778e 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c
@@ -501,7 +501,9 @@ const struct atomisp_format_bridge atomisp_output_fmts[] = {
.mbus_code = MEDIA_BUS_FMT_JPEG_1X8,
.sh_fmt = CSS_FRAME_FORMAT_BINARY_8,
.description = "JPEG"
- }, {
+ },
+#if 0
+ {
/* This is a custom format being used by M10MO to send the RAW data */
.pixelformat = V4L2_PIX_FMT_CUSTOM_M10MO_RAW,
.depth = 8,
@@ -509,6 +511,7 @@ const struct atomisp_format_bridge atomisp_output_fmts[] = {
.sh_fmt = CSS_FRAME_FORMAT_BINARY_8,
.description = "Custom RAW for M10MO"
},
+#endif
};
const struct atomisp_format_bridge *atomisp_get_format_bridge(
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
index 70b53988553c..f3e18d627b0a 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
@@ -48,7 +48,9 @@ const struct atomisp_in_fmt_conv atomisp_in_fmt_conv[] = {
{ V4L2_MBUS_FMT_CUSTOM_NV12, 12, 12, CSS_FRAME_FORMAT_NV12, 0,
CSS_FRAME_FORMAT_NV12 },
{ V4L2_MBUS_FMT_CUSTOM_NV21, 12, 12, CSS_FRAME_FORMAT_NV21, 0,
CSS_FRAME_FORMAT_NV21 },
{ V4L2_MBUS_FMT_CUSTOM_YUV420, 12, 12,
ATOMISP_INPUT_FORMAT_YUV420_8_LEGACY, 0, IA_CSS_STREAM_FORMAT_YUV420_8_LEGACY },
+#if 0
{ V4L2_MBUS_FMT_CUSTOM_M10MO_RAW, 8, 8, CSS_FRAME_FORMAT_BINARY_8, 0,
IA_CSS_STREAM_FORMAT_BINARY_8 },
+#endif
/* no valid V4L2 MBUS code for metadata format, so leave it 0. */
{ 0, 0, 0, ATOMISP_INPUT_FORMAT_EMBEDDED, 0,
IA_CSS_STREAM_FORMAT_EMBEDDED },
{}
--
2.15.1
[PATCH v1 10/10] staging: atomisp: Fix DMI matching entry for MRD7
MRD7 board has in particular
Base Board Information
Manufacturer: Intel Corp.
Product Name: TABLET
Version: MRD 7
Fix the DMI matching entry for it.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
.../staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 8408a58ed764..d8b7183db252 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -286,7 +286,8 @@ static const struct dmi_system_id gmin_vars[] = {
{
.ident = "MRD7",
.matches = {
- DMI_MATCH(DMI_BOARD_NAME, "MRD7"),
+ DMI_MATCH(DMI_BOARD_NAME, "TABLET"),
+ DMI_MATCH(DMI_BOARD_VERSION, "MRD 7"),
},
.driver_data = mrd7_vars,
},
--
2.15.1
[PATCH v1 03/10] staging: atomisp: lm3554: Fix control values
Driver fails to initialize due to insane settings in the
control init array.
Fix this by moving to sanity.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/staging/media/atomisp/i2c/atomisp-lm3554.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
index 4fd9f538ac95..974b6ff50c7a 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
@@ -562,10 +562,10 @@ static const struct v4l2_ctrl_config lm3554_controls[] = {
{
.ops = _ops,
.id = V4L2_CID_FLASH_STATUS,
-.type = V4L2_CTRL_TYPE_BOOLEAN,
+.type = V4L2_CTRL_TYPE_INTEGER,
.name = "Flash Status",
-.min = 0,
-.max = 100,
+.min = ATOMISP_FLASH_STATUS_OK,
+.max = ATOMISP_FLASH_STATUS_TIMEOUT,
.step = 1,
.def = ATOMISP_FLASH_STATUS_OK,
.flags = 0,
@@ -574,10 +574,10 @@ static const struct v4l2_ctrl_config lm3554_controls[] = {
{
.ops = _ops,
.id = V4L2_CID_FLASH_STATUS_REGISTER,
-.type = V4L2_CTRL_TYPE_BOOLEAN,
+.type = V4L2_CTRL_TYPE_INTEGER,
.name = "Flash Status Register",
.min = 0,
-.max = 100,
+.max = 255,
.step = 1,
.def = 0,
.flags = 0,
--
2.15.1
[PATCH v1 05/10] staging: atomisp: Remove non-ACPI leftovers
Since all drivers are solely requiring ACPI enumeration, there is no
need to additionally check for legacy platform data or ACPI handle.
Remove leftovers from the sensors and platform code.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/staging/media/atomisp/i2c/atomisp-gc0310.c | 10 ++---
drivers/staging/media/atomisp/i2c/atomisp-gc2235.c | 8 +---
drivers/staging/media/atomisp/i2c/atomisp-lm3554.c | 28 --
.../staging/media/atomisp/i2c/atomisp-mt9m114.c| 8 ++--
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c | 10 ++---
drivers/staging/media/atomisp/i2c/atomisp-ov2722.c | 17 ++---
.../media/atomisp/i2c/ov5693/atomisp-ov5693.c | 12 ++
drivers/staging/media/atomisp/i2c/ov8858.c | 43 +++---
.../platform/intel-mid/atomisp_gmin_platform.c | 6 +--
9 files changed, 49 insertions(+), 93 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
index e70d8afcc229..61b7598469eb 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
@@ -1370,13 +1370,9 @@ static int gc0310_probe(struct i2c_client *client)
dev->fmt_idx = 0;
v4l2_i2c_subdev_init(&(dev->sd), client, _ops);
- if (ACPI_COMPANION(>dev))
- pdata = gmin_camera_platform_data(>sd,
- ATOMISP_INPUT_FORMAT_RAW_8,
- atomisp_bayer_order_grbg);
- else
- pdata = client->dev.platform_data;
-
+ pdata = gmin_camera_platform_data(>sd,
+ ATOMISP_INPUT_FORMAT_RAW_8,
+ atomisp_bayer_order_grbg);
if (!pdata) {
ret = -EINVAL;
goto out_free;
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
b/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
index 85da5fe24033..d8de46da64ae 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
@@ -1108,9 +1108,7 @@ static int gc2235_probe(struct i2c_client *client)
dev->fmt_idx = 0;
v4l2_i2c_subdev_init(&(dev->sd), client, _ops);
- gcpdev = client->dev.platform_data;
- if (ACPI_COMPANION(>dev))
- gcpdev = gmin_camera_platform_data(>sd,
+ gcpdev = gmin_camera_platform_data(>sd,
ATOMISP_INPUT_FORMAT_RAW_10,
atomisp_bayer_order_grbg);
@@ -1147,10 +1145,8 @@ static int gc2235_probe(struct i2c_client *client)
if (ret)
gc2235_remove(client);
- if (ACPI_HANDLE(>dev))
- ret = atomisp_register_i2c_module(>sd, gcpdev, RAW_CAMERA);
+ return atomisp_register_i2c_module(>sd, gcpdev, RAW_CAMERA);
- return ret;
out_free:
v4l2_device_unregister_subdev(>sd);
kfree(dev);
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
index 974b6ff50c7a..7098bf317f16 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
@@ -824,22 +824,15 @@ static void *lm3554_platform_data_func(struct i2c_client
*client)
{
static struct lm3554_platform_data platform_data;
- if (ACPI_COMPANION(>dev)) {
- platform_data.gpio_reset =
- desc_to_gpio(gpiod_get_index(&(client->dev),
+ platform_data.gpio_reset =
+ desc_to_gpio(gpiod_get_index(>dev,
NULL, 2, GPIOD_OUT_LOW));
- platform_data.gpio_strobe =
- desc_to_gpio(gpiod_get_index(&(client->dev),
+ platform_data.gpio_strobe =
+ desc_to_gpio(gpiod_get_index(>dev,
NULL, 0, GPIOD_OUT_LOW));
- platform_data.gpio_torch =
- desc_to_gpio(gpiod_get_index(&(client->dev),
+ platform_data.gpio_torch =
+ desc_to_gpio(gpiod_get_index(>dev,
NULL, 1, GPIOD_OUT_LOW));
- } else {
- platform_data.gpio_reset = -1;
- platform_data.gpio_strobe = -1;
- platform_data.gpio_torch = -1;
- }
-
dev_info(>dev, "camera pdata: lm3554: reset: %d strobe %d torch
%d\n",
platform_data.gpio_reset, platform_data.gpio_strobe,
platform_data.gpio_torch);
@@ -868,10 +861,7 @@ static int lm3554_probe(struct i2c_client *client)
if (!flash)
return -ENOMEM;
- flash->pdata = client->dev.platform_d
[PATCH v1 02/10] staging: atomisp: Remove duplicate NULL-check
GPIO framework checks for NULL pointer when gpiod_set_value() is called.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
.../staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index a5d0dd88a8bc..8fb5147531a5 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -394,7 +394,7 @@ static int gmin_gpio0_ctrl(struct v4l2_subdev *subdev, int
on)
{
struct gmin_subdev *gs = find_gmin_subdev(subdev);
- if (gs && gs->gpio0) {
+ if (gs) {
gpiod_set_value(gs->gpio0, on);
return 0;
}
@@ -405,7 +405,7 @@ static int gmin_gpio1_ctrl(struct v4l2_subdev *subdev, int
on)
{
struct gmin_subdev *gs = find_gmin_subdev(subdev);
- if (gs && gs->gpio1) {
+ if (gs) {
gpiod_set_value(gs->gpio1, on);
return 0;
}
--
2.15.1
[PATCH v1 06/10] staging: atomisp: Switch to use struct device_driver directly
In a preparation of split PCI glue driver from core part, convert
the driver to use more generic struct device_driver.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
.../staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c | 17 -
.../staging/media/atomisp/pci/atomisp2/atomisp_drvfs.h | 5 ++---
.../staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 4 +---
3 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c
index 7129b88456cb..ceedb82b6beb 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c
@@ -15,9 +15,9 @@
*
*/
+#include
#include
#include
-#include
#include "atomisp_compat.h"
#include "atomisp_internal.h"
@@ -33,7 +33,7 @@
*bit 2: memory statistic
*/
struct _iunit_debug {
- struct pci_driver *drv;
+ struct device_driver*drv;
struct atomisp_device *isp;
unsigned intdbglvl;
unsigned intdbgfun;
@@ -164,26 +164,25 @@ static const struct driver_attribute iunit_drvfs_attrs[]
= {
__ATTR(dbgopt, 0644, iunit_dbgopt_show, iunit_dbgopt_store),
};
-static int iunit_drvfs_create_files(struct pci_driver *drv)
+static int iunit_drvfs_create_files(struct device_driver *drv)
{
int i, ret = 0;
for (i = 0; i < ARRAY_SIZE(iunit_drvfs_attrs); i++)
- ret |= driver_create_file(&(drv->driver),
- _drvfs_attrs[i]);
+ ret |= driver_create_file(drv, _drvfs_attrs[i]);
return ret;
}
-static void iunit_drvfs_remove_files(struct pci_driver *drv)
+static void iunit_drvfs_remove_files(struct device_driver *drv)
{
int i;
for (i = 0; i < ARRAY_SIZE(iunit_drvfs_attrs); i++)
- driver_remove_file(&(drv->driver), _drvfs_attrs[i]);
+ driver_remove_file(drv, _drvfs_attrs[i]);
}
-int atomisp_drvfs_init(struct pci_driver *drv, struct atomisp_device *isp)
+int atomisp_drvfs_init(struct device_driver *drv, struct atomisp_device *isp)
{
int ret;
@@ -193,7 +192,7 @@ int atomisp_drvfs_init(struct pci_driver *drv, struct
atomisp_device *isp)
ret = iunit_drvfs_create_files(iunit_debug.drv);
if (ret) {
dev_err(atomisp_dev, "drvfs_create_files error: %d\n", ret);
- iunit_drvfs_remove_files(drv);
+ iunit_drvfs_remove_files(iunit_debug.drv);
}
return ret;
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.h
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.h
index b91bfef21639..7c99240d107a 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.h
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.h
@@ -18,8 +18,7 @@
#ifndef__ATOMISP_DRVFS_H__
#define__ATOMISP_DRVFS_H__
-extern int atomisp_drvfs_init(struct pci_driver *drv, struct atomisp_device
- *isp);
-extern void atomisp_drvfs_exit(void);
+int atomisp_drvfs_init(struct device_driver *drv, struct atomisp_device *isp);
+void atomisp_drvfs_exit(void);
#endif /* __ATOMISP_DRVFS_H__ */
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index 3c260f8b52e2..7a9efc6847ca 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -1152,8 +1152,6 @@ static int init_atomisp_wdts(struct atomisp_device *isp)
return err;
}
-static struct pci_driver atomisp_pci_driver;
-
#define ATOM_ISP_PCI_BAR 0
static int atomisp_pci_probe(struct pci_dev *dev,
@@ -1451,7 +1449,7 @@ static int atomisp_pci_probe(struct pci_dev *dev,
isp->firmware = NULL;
isp->css_env.isp_css_fw.data = NULL;
- atomisp_drvfs_init(_pci_driver, isp);
+ atomisp_drvfs_init(>driver->driver, isp);
return 0;
--
2.15.1
Re: [BUG] atomisp_ov2680 not initializing correctly
On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote: > Cc Alan and Andy. > > On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke wrote: > > Dear all, > > > > I am trying to get the cameras in a Lenovo IdeaPad Miix 320 (Atom > > x5-Z8350 BayTrail) to work. The front camera is an ov2680. With > > kernel > > 4.14.4 and 4.15rc3 I see the following dmesg output: It seems I forgot to send the rest of the patches I did while ago against AtomISP code. It includes switch to normal DMI matching instead of the crap we have there right now. WRT to the messages below it seems we have no platform data for that device. It needs to be added. In any case, I have no firmware to test BayTrail hardware I have (MRD7). The driver claims it needs: Firmware file: shisp_2400b0_v21.bin Version string: irci_stable_candrpv_0415_20150521_0458 What I have is: Version string: irci_stable_candrpv_0415_20150423_1753 SHA1: 548d26a9b5daedbeb59a46ea1da69757d92cd4d6 shisp_2400b0_v21.bin > > [ 21.469907] ov2680: module is from the staging directory, the > > quality > > is unknown, you have been warned. > > [ 21.492774] ov2680 i2c-OVTI2680:00: gmin: initializing atomisp > > module > > subdev data.PMIC ID 1 > > [ 21.492891] acpi OVTI2680:00: Failed to find gmin variable > > OVTI2680:00_CamClk > > [ 21.492974] acpi OVTI2680:00: Failed to find gmin variable > > OVTI2680:00_ClkSrc > > [ 21.493090] acpi OVTI2680:00: Failed to find gmin variable > > OVTI2680:00_CsiPort > > [ 21.493209] acpi OVTI2680:00: Failed to find gmin variable > > OVTI2680:00_CsiLanes > > [ 21.493511] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P8SX > > not > > found, using dummy regulator > > [ 21.493550] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V2P8SX > > not > > found, using dummy regulator > > [ 21.493569] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P2A > > not > > found, using dummy regulator > > [ 21.493585] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply > > VPROG4B > > not found, using dummy regulator > > [ 21.568134] ov2680 i2c-OVTI2680:00: camera pdata: port: 0 lanes: > > 1 > > order: 0002 > > [ 21.568257] ov2680 i2c-OVTI2680:00: read from offset 0x300a error > > -121 > > [ 21.568265] ov2680 i2c-OVTI2680:00: sensor_id_high = 0x > > [ 21.568269] ov2680 i2c-OVTI2680:00: ov2680_detect err s_config. > > [ 21.568291] ov2680 i2c-OVTI2680:00: sensor power-gating failed > > > > Afterwards I do not get a camera device. > > > > Am I missing some firmware or dependency? See above. > > Can I somehow help to improve > > the driver? Yes, definitely, but first of all we need to find at least one device and corresponding firmware where it actually works. For me it doesn't generate any interrupt (after huge hacking to make that firmware loaded and settings / platform data applied). -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy
Re: [trivial PATCH] treewide: Align function definition open/close braces
On Mon, Dec 18, 2017 at 2:28 AM, Joe Perches <j...@perches.com> wrote:
> Some functions definitions have either the initial open brace and/or
> the closing brace outside of column 1.
>
> Move those braces to column 1.
>
> This allows various function analyzers like gnu complexity to work
> properly for these modified functions.
>
> Miscellanea:
>
> o Remove extra trailing ; and blank line from xfs_agf_verify
>
> Signed-off-by: Joe Perches <j...@perches.com>
> drivers/platform/x86/eeepc-laptop.c | 2 +-
> diff --git a/drivers/platform/x86/eeepc-laptop.c
> b/drivers/platform/x86/eeepc-laptop.c
> index 5a681962899c..4c38904a8a32 100644
> --- a/drivers/platform/x86/eeepc-laptop.c
> +++ b/drivers/platform/x86/eeepc-laptop.c
> @@ -492,7 +492,7 @@ static void eeepc_platform_exit(struct eeepc_laptop
> *eeepc)
> * potentially bad time, such as a timer interrupt.
> */
> static void tpd_led_update(struct work_struct *work)
> - {
> +{
> struct eeepc_laptop *eeepc;
>
> eeepc = container_of(work, struct eeepc_laptop, tpd_led_work);
> diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c
> index a319bf1e49de..ef5c16dfabfa 100644
Acked-by: Andy Shevchenko <andy.shevche...@gmail.com>
for PDx86 changes.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2] [media] staging: atomisp: convert timestamps to ktime_t
On Mon, 2017-11-27 at 16:21 +0100, Arnd Bergmann wrote:
> timespec overflows in 2038 on 32-bit architectures, and the
> getnstimeofday() suffers from possible time jumps, so the
> timestamps here are better done using ktime_get(), which has
> neither of those problems.
>
> In case of ov2680, we don't seem to use the timestamp at
> all, so I just remove it.
>
Yep,
Reviewed-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
> v2: use min_t() as suggested by Andy Shevchenko
> ---
> drivers/staging/media/atomisp/i2c/ov2680.h| 1 -
> .../staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c | 19
> ---
> drivers/staging/media/atomisp/i2c/ov5693/ov5693.h | 2 +-
> 3 files changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/staging/media/atomisp/i2c/ov2680.h
> b/drivers/staging/media/atomisp/i2c/ov2680.h
> index bf4897347df7..03f75dd80f87 100644
> --- a/drivers/staging/media/atomisp/i2c/ov2680.h
> +++ b/drivers/staging/media/atomisp/i2c/ov2680.h
> @@ -174,7 +174,6 @@ struct ov2680_format {
> struct mutex input_lock;
> struct v4l2_ctrl_handler ctrl_handler;
> struct camera_sensor_platform_data *platform_data;
> - struct timespec timestamp_t_focus_abs;
> int vt_pix_clk_freq_mhz;
> int fmt_idx;
> int run_mode;
> diff --git a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
> b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
> index 3e7c3851280f..9fa25bb8f1ee 100644
> --- a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
> +++ b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
> @@ -973,7 +973,7 @@ static int ov5693_t_focus_abs(struct v4l2_subdev
> *sd, s32 value)
> if (ret == 0) {
> dev->number_of_steps = value - dev->focus;
> dev->focus = value;
> - getnstimeofday(&(dev->timestamp_t_focus_abs));
> + dev->timestamp_t_focus_abs = ktime_get();
> } else
> dev_err(>dev,
> "%s: i2c failed. ret %d\n", __func__, ret);
> @@ -993,16 +993,13 @@ static int ov5693_q_focus_status(struct
> v4l2_subdev *sd, s32 *value)
> {
> u32 status = 0;
> struct ov5693_device *dev = to_ov5693_sensor(sd);
> - struct timespec temptime;
> - const struct timespec timedelay = {
> - 0,
> - min((u32)abs(dev->number_of_steps) *
> DELAY_PER_STEP_NS,
> - (u32)DELAY_MAX_PER_STEP_NS),
> - };
> -
> - getnstimeofday();
> - temptime = timespec_sub(temptime, (dev-
> >timestamp_t_focus_abs));
> - if (timespec_compare(, ) <= 0) {
> + ktime_t temptime;
> + ktime_t timedelay = ns_to_ktime(min_t(u32,
> + abs(dev->number_of_steps) *
> DELAY_PER_STEP_NS,
> + DELAY_MAX_PER_STEP_NS));
> +
> + temptime = ktime_sub(ktime_get(), (dev-
> >timestamp_t_focus_abs));
> + if (ktime_compare(temptime, timedelay) <= 0) {
> status |= ATOMISP_FOCUS_STATUS_MOVING;
> status |= ATOMISP_FOCUS_HP_IN_PROGRESS;
> } else {
> diff --git a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
> b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
> index 2ea63807c56d..68cfcb4a6c3c 100644
> --- a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
> +++ b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
> @@ -221,7 +221,7 @@ struct ov5693_device {
> struct v4l2_ctrl_handler ctrl_handler;
>
> struct camera_sensor_platform_data *platform_data;
> - struct timespec timestamp_t_focus_abs;
> + ktime_t timestamp_t_focus_abs;
> int vt_pix_clk_freq_mhz;
> int fmt_idx;
> int run_mode;
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
Re: [PATCH 7/8] [media] staging: atomisp: convert timestamps to ktime_t
On Mon, 2017-11-27 at 14:19 +0100, Arnd Bergmann wrote: > timespec overflows in 2038 on 32-bit architectures, and the > getnstimeofday() suffers from possible time jumps, so the > timestamps here are better done using ktime_get(), which has > neither of those problems. > > In case of ov2680, we don't seem to use the timestamp at > all, so I just remove it. > > + ktime_t timedelay = ns_to_ktime( > min((u32)abs(dev->number_of_steps) * > DELAY_PER_STEP_NS, > - (u32)DELAY_MAX_PER_STEP_NS), > - }; > + (u32)DELAY_MAX_PER_STEP_NS)); Since you are touching this, it might make sense to convert to min_t(u32, ...) ...and locate lines something like: ktime_t timeday = ns_to_ktime(min_t(u32, param1, param2)); >From my pov will make readability better. -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy
[PATCH v1] [media] v4l2-ctrls: Don't validate BITMASK twice
There is no need to repeat what check_range() does for us, i.e. BITMASK
validation in v4l2_ctrl_new().
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/media/v4l2-core/v4l2-ctrls.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index c230bd5c6558..cbb2ef43945f 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2013,10 +2013,6 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
handler_set_err(hdl, err);
return NULL;
}
- if (type == V4L2_CTRL_TYPE_BITMASK && ((def & ~max) || min || step)) {
- handler_set_err(hdl, -ERANGE);
- return NULL;
- }
if (is_array &&
(type == V4L2_CTRL_TYPE_BUTTON ||
type == V4L2_CTRL_TYPE_CTRL_CLASS)) {
--
2.14.2
[PATCH v1 15/15] media: i2c: adv748x: Remove duplicate NULL check
Since i2c_unregister_device() became NULL-aware we may remove duplicate
NULL check.
Cc: Kieran Bingham <kieran.bing...@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mche...@kernel.org>
Cc: linux-media@vger.kernel.org
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/media/i2c/adv748x/adv748x-core.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/adv748x/adv748x-core.c
b/drivers/media/i2c/adv748x/adv748x-core.c
index 5ee14f2c2747..10c3d469175c 100644
--- a/drivers/media/i2c/adv748x/adv748x-core.c
+++ b/drivers/media/i2c/adv748x/adv748x-core.c
@@ -225,10 +225,8 @@ static void adv748x_unregister_clients(struct
adv748x_state *state)
{
unsigned int i;
- for (i = 1; i < ARRAY_SIZE(state->i2c_clients); ++i) {
- if (state->i2c_clients[i])
- i2c_unregister_device(state->i2c_clients[i]);
- }
+ for (i = 1; i < ARRAY_SIZE(state->i2c_clients); ++i)
+ i2c_unregister_device(state->i2c_clients[i]);
}
static int adv748x_initialise_clients(struct adv748x_state *state)
--
2.14.2
[PATCH v1 14/15] media: adv7180: Remove duplicate checks
Since i2c_unregister_device() became NULL-aware we may remove duplicate checks. Cc: Lars-Peter Clausen <l...@metafoo.de> Cc: Mauro Carvalho Chehab <mche...@kernel.org> Cc: linux-media@vger.kernel.org Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> --- drivers/media/i2c/adv7180.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c index 3df28f2f9b38..c7e2ee7fe8a4 100644 --- a/drivers/media/i2c/adv7180.c +++ b/drivers/media/i2c/adv7180.c @@ -1366,11 +1366,9 @@ static int adv7180_probe(struct i2c_client *client, err_free_ctrl: adv7180_exit_controls(state); err_unregister_vpp_client: - if (state->chip_info->flags & ADV7180_FLAG_I2P) - i2c_unregister_device(state->vpp_client); + i2c_unregister_device(state->vpp_client); err_unregister_csi_client: - if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) - i2c_unregister_device(state->csi_client); + i2c_unregister_device(state->csi_client); mutex_destroy(>mutex); return ret; } @@ -1388,10 +1386,8 @@ static int adv7180_remove(struct i2c_client *client) media_entity_cleanup(>entity); adv7180_exit_controls(state); - if (state->chip_info->flags & ADV7180_FLAG_I2P) - i2c_unregister_device(state->vpp_client); - if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) - i2c_unregister_device(state->csi_client); + i2c_unregister_device(state->vpp_client); + i2c_unregister_device(state->csi_client); adv7180_set_power_pin(state, false); -- 2.14.2
Re: [PATCH v1 00/13] staging: atomisp: clean up bomb
On Wed, 2017-10-18 at 23:53 +0300, Sakari Ailus wrote: > On Wed, Sep 27, 2017 at 09:24:55PM +0300, Andy Shevchenko wrote: > > The driver has been submitted with a limitation to few platforms and > > sensors which it does support. Even though two sensor drivers have > > no > > users neither on ACPI-enabled platforms, nor in current Linux kernel > > code. Patches 1 and 2 removes those drivers for now. > > > > It seems new contributors follow cargo cult programming done by the > > original driver developers. It's neither good for code, nor for > > reviewing process. To avoid such issues in the future here are few > > clean > > up patches, i.e. patches 3, 4, 6. 13. > > > > On top of this here are clean ups with regard to GPIO use. One may > > consider this as an intermediate clean up. This part toughly related > > to > > removal of unused sensor drivers in patches 1 and 2. > > > > Patch series has been partially compile tested. It would be nice to > > see > > someone with hardware to confirm it doesn't break anything. > > > > Andy Shevchenko (13): > > staging: atomisp: Remove IMX sensor support > > staging: atomisp: Remove AP1302 sensor support > > staging: atomisp: Use module_i2c_driver() macro > > staging: atomisp: Switch i2c drivers to use ->probe_new() > > staging: atomisp: Do not set GPIO twice > > staging: atomisp: Remove unneeded gpio.h inclusion > > staging: atomisp: Remove ->gpio_ctrl() callback > > staging: atomisp: Remove ->power_ctrl() callback > > staging: atomisp: Remove unused members of > > camera_sensor_platform_data > > staging: atomisp: Remove Gmin dead code #1 > > staging: atomisp: Remove Gmin dead code #2 > > staging: atomisp: Remove duplicate declaration in header > > staging: atomisp: Remove FSF snail address > > After chatting with Andy we figured out the first patch was actually > missing from the set, both on the mailing list and Patchwork. I've > uploaded > it to the same branch, and the patch itself is here: > > <URL:https://git.linuxtv.org/sailus/media_tree.git/commit/?h=atomisp-a > ndy=5ef68fbdbb80e72f3239363289fbf12f673988a1>; > Looks good, thanks! -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy
Re: [PATCH v2 08/12] intel-ipu3: params: compute and program ccs
On Wed, Oct 11, 2017 at 5:01 PM, Tuukka Toivonen
<tuukka.toivo...@intel.com> wrote:
> On Wed, 2017-10-11 at 16:31 +0300, Andy Shevchenko wrote:
>> On Wed, Oct 11, 2017 at 10:29 AM, sakari.ai...@linux.intel.com
>> <sakari.ai...@linux.intel.com> wrote:
>> > On Wed, Oct 11, 2017 at 04:14:37AM +, Zhi, Yong wrote:
>> > > > > +static unsigned int ipu3_css_scaler_get_exp(unsigned int
>> > > > > counter,
>> > > > > + unsigned int
>> > > > > divider) {
>> > > > > + unsigned int i = 0;
>> > > > > +
>> > > > > + while (counter <= divider / 2) {
>> > > > > + divider /= 2;
>> > > > > + i++;
>> > > > > + }
>> > > > > +
>> > > > > + return i;
>> Roughly like
>>
>> if (!counter || divider < counter)
>> return 0;
>> return order_base_2(divider) - order_base_2(counter);
>
> The original loop is typical ran just couple of times, so I think
> that fls or division are probably slower than the original loop.
> Furthermore, these "optimizations" are also harder to read, so in
> my opinion there's no advantage in using them.
Honestly I'm opposing that.
It took me about minute to be clear what is going on on that loop
while fls() / ffs() / ilog2() like stuff can be read fast.
Like
int shift = order_base_2(divider) - order_base_2(counter);
return shift > 0 ? shift : 0;
And frankly I don't care about under the hoods of order_base_2(). I
care about this certain piece of code to be simpler.
One may put a comment line:
# Get log2 of how divider bigger than counter
And thinking more while writing this message the use of order_base_2()
actually explains what's going on here.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 08/12] intel-ipu3: params: compute and program ccs
On Wed, Oct 11, 2017 at 10:29 AM, sakari.ai...@linux.intel.com
<sakari.ai...@linux.intel.com> wrote:
> On Wed, Oct 11, 2017 at 04:14:37AM +, Zhi, Yong wrote:
>> > > +static unsigned int ipu3_css_scaler_get_exp(unsigned int counter,
>> > > + unsigned int divider) {
>> > > + unsigned int i = 0;
>> > > +
>> > > + while (counter <= divider / 2) {
>> > > + divider /= 2;
>> > > + i++;
>> > > + }
>> > > +
>> > > + return i;
> return (!counter || divider < counter) ?
>0 : fls(divider / counter) - 1;
Extra division is here (I dunno if counter is always power of 2 but it
doesn't matter for compiler).
Basically above calculates how much bits we need to shift divider to
get it less than counter.
I would consider to use something from log2.h.
Roughly like
if (!counter || divider < counter)
return 0;
return order_base_2(divider) - order_base_2(counter);
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v3] staging: atomisp: add a driver for ov5648 camera sensor
On Mon, 2017-10-02 at 21:30 +0200, Devid Antonio Filoni wrote:
> The ov5648 5-megapixel camera sensor from OmniVision supports up to
> 2592x1944
> resolution and MIPI CSI-2 interface. Output format is raw sRGB/Bayer
> with
> 10 bits per colour (SGRBG10_1X10).
>
> This patch is a port of ov5648 driver after applying following
> 01org/ProductionKernelQuilts patches:
> - 0004-ov2680-ov5648-Fork-lift-source-from-CTS.patch
> - 0005-ov2680-ov5648-gminification.patch
> - 0006-ov5648-Focus-support.patch
> - 0007-Fix-resolution-issues-on-rear-camera.patch
> - 0008-ov2680-ov5648-Enabled-the-set_exposure-functions.patch
> - 0010-IRDA-cameras-mode-list-cleanup-unification.patch
> - 0012-ov5648-Add-1296x972-binned-mode.patch
> - 0014-ov5648-Adapt-to-Atomisp2-Gmin-VCM-framework.patch
> - 0015-dw9714-Gmin-Atomisp-specific-VCM-driver.patch
> - 0017-ov5648-Fix-deadlock-on-I2C-error.patch
> - 0018-gc2155-Fix-deadlock-on-error.patch
> - 0019-ov5648-Add-1280x960-binned-mode.patch
> - 0020-ov5648-Make-1280x960-as-default-video-resolution.patch
> - 0021-MALATA-Fix-testCameraToSurfaceTextureMetadata-CTS.patch
> - 0023-OV5648-Added-5MP-video-resolution.patch
>
> New changes introduced during the port:
> - Rename entity types to entity functions
> - Replace v4l2_subdev_fh by v4l2_subdev_pad_config
> - Make use of media_bus_format enum
> - Rename media_entity_init function to media_entity_pads_init
> - Replace try_mbus_fmt by set_fmt
> - Replace s_mbus_fmt by set_fmt
> - Replace g_mbus_fmt by get_fmt
> - Use s_ctrl/g_volatile_ctrl instead of ctrl core ops
> - Update gmin platform API path
> - Constify acpi_device_id
> - Add "INT5648" value to acpi_device_id
> - Fix some checkpatch errors and warnings
> - Remove FSF's mailing address from the sample GPL notice
>
> "INT5648" ACPI device id can be found in following production
> hardware:
> BIOS Information
> Vendor: LENOVO
> Version: 1HCN40WW
> Release Date: 11/04/2016
> ...
> BIOS Revision: 0.40
> Firmware Revision: 0.0
> ...
> System Information
> Manufacturer: LENOVO
> Product Name: 80SG
> Version: MIIX 310-10ICR
> ...
> SKU Number: LENOVO_MT_80SG_BU_idea_FM_MIIX 310-10ICR
> Family: IDEAPAD
> ...
>
> Device DSDT excerpt:
> Device (CA00)
> {
> Name (_ADR, Zero) // _ADR: Address
> Name (_HID, "INT5648") // _HID: Hardware ID
> Name (_CID, "INT5648") // _CID: Compatible ID
> Name (_SUB, "INTL") // _SUB: Subsystem ID
> Name (_DDN, "ov5648") // _DDN: DOS Device Name
> ...
>
> I was not able to properly test this patch on my Lenovo Miix 310 due
> to other
> issues with atomisp,
Can you elaborate this a bit?
> the output is the same as ov2680 driver (OVTI2680)
> which is very similar.
>
Other than above the patch looks good enough for staging, though still
requires a lot of clean up work.
Reviewed-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> Signed-off-by: Devid Antonio Filoni <d.fil...@ubuntu.com>
> ---
> Changes in v2:
> - Fix indentation
> - Add atomisp prefix to Kconfig option
>
> Changes in v3:
> - Use module_i2c_driver() macro
> - Switch i2c drivers to use ->probe_new()
> - Remove unused ->gpio_ctrl() callback
> - Remove unused ->power_ctrl() callback
> - Remove unneeded header inclusions
> - Sort header inclusions alphabetically
> - Replace kzalloc with devm_kzalloc
> - Remove "XXOV5648" acpi_device_id, we don't know if it's used in any
> production device
> - Use reverse XMAS tree declarations
> - Fix comments style
> - Remove __func__ from all dev_{dbg,info,err}() calls
> - Add missing new line chars in all dev_{dbg,info,err}() calls
> - Remove useless dev_{dbg,err}() calls
> - Fix all checkpatch.pl issues
>
> drivers/staging/media/atomisp/i2c/Kconfig | 12 +
> drivers/staging/media/atomisp/i2c/Makefile |1 +
> drivers/staging/media/atomisp/i2c/atomisp-ov5648.c | 1787
>
> drivers/staging/media/atomisp/i2c/ov5648.h | 828 +
> 4 files changed, 2628 insertions(+)
> create mode 100644 drivers/staging/media/atomisp/i2c/atomisp-ov5648.c
> create mode 100644 drivers/staging/media/atomisp/i2c/ov5648.h
>
> diff --git a/drivers/staging/media/atomisp/i2c/Kconfig
> b/drivers/staging/media/atomisp/i2c/Kconfig
> index a76f17d..6bd849d 100644
> --- a/drivers/staging/media/atomisp/i2c/Kconfig
> +++ b/drivers/staging/media/atomisp/i2c/Kconfig
> @@ -83,6 +83,18 @@ config
Re: [PATCH v2] staging: atomisp: add a driver for ov5648 camera sensor
On Sun, Sep 24, 2017 at 5:59 PM, Devid Antonio Floni <d.fil...@ubuntu.com> wrote: > The ov5648 5-megapixel camera sensor from OmniVision supports up to 2592x1944 > resolution and MIPI CSI-2 interface. Output format is raw sRGB/Bayer with > 10 bits per colour (SGRBG10_1X10). > > This patch is a port of ov5648 driver after applying following > 01org/ProductionKernelQuilts patches: > - 0004-ov2680-ov5648-Fork-lift-source-from-CTS.patch > - 0005-ov2680-ov5648-gminification.patch > - 0006-ov5648-Focus-support.patch > - 0007-Fix-resolution-issues-on-rear-camera.patch > - 0008-ov2680-ov5648-Enabled-the-set_exposure-functions.patch > - 0010-IRDA-cameras-mode-list-cleanup-unification.patch > - 0012-ov5648-Add-1296x972-binned-mode.patch > - 0014-ov5648-Adapt-to-Atomisp2-Gmin-VCM-framework.patch > - 0015-dw9714-Gmin-Atomisp-specific-VCM-driver.patch > - 0017-ov5648-Fix-deadlock-on-I2C-error.patch > - 0018-gc2155-Fix-deadlock-on-error.patch > - 0019-ov5648-Add-1280x960-binned-mode.patch > - 0020-ov5648-Make-1280x960-as-default-video-resolution.patch > - 0021-MALATA-Fix-testCameraToSurfaceTextureMetadata-CTS.patch > - 0023-OV5648-Added-5MP-video-resolution.patch > > New changes introduced during the port: > - Rename entity types to entity functions > - Replace v4l2_subdev_fh by v4l2_subdev_pad_config > - Make use of media_bus_format enum > - Rename media_entity_init function to media_entity_pads_init > - Replace try_mbus_fmt by set_fmt > - Replace s_mbus_fmt by set_fmt > - Replace g_mbus_fmt by get_fmt > - Use s_ctrl/g_volatile_ctrl instead of ctrl core ops > - Update gmin platform API path > - Constify acpi_device_id > - Add "INT5648" value to acpi_device_id > - Fix some checkpatch errors and warnings > - Remove FSF's mailing address from the sample GPL notice > > Changes in v2: > - Fix indentation > - Add atomisp prefix to Kconfig option I discussed with Sakari about my review and we agreed that two things that I have mentioned (converting to smbus calls and regulator framework) would be a material for future changes. Other than that, please, address the rest of comments and we will be fine. You may also refer to my last patch series WRT atomisp driver where I tried to address my own comments to the rest of the code. -- With Best Regards, Andy Shevchenko
Re: [PATCH 1/1] staging: atomisp: Update TODO regarding sensors
On Mon, Sep 25, 2017 at 2:20 PM, Sakari Ailus <sakari.ai...@linux.intel.com> wrote: > There was no specific item regarding what should be done to sensor, lens > and flash drivers. Add one, to replace the vague item denoting support > only to particular sensor, lens and flash devices. > I think it's right direction, though Alan would be one who can confirm. Additionally the lm3554.c should gone in favour the one under driver/leds/. > Signed-off-by: Sakari Ailus <sakari.ai...@linux.intel.com> > --- > drivers/staging/media/atomisp/TODO | 19 --- > 1 file changed, 12 insertions(+), 7 deletions(-) > > diff --git a/drivers/staging/media/atomisp/TODO > b/drivers/staging/media/atomisp/TODO > index 737452c..a960247 100644 > --- a/drivers/staging/media/atomisp/TODO > +++ b/drivers/staging/media/atomisp/TODO > @@ -36,13 +36,18 @@ > there are any specific things that can be done to fold in support for > multiple firmware versions. > > +8. Switch to V4L2 async API to set up sensor, lens and flash devices. > + Control those devices using V4L2 sub-device API without custom > + extensions. > > -Limitations: > +9. Switch to standard V4L2 sub-device API for sensor, lens and flash > + drivers. In particular, the user space API needs to support V4L2 > + controls as defined in the V4L2 spec and references to atomisp must be > + removed from these drivers. > > -1. Currently the patch only support some camera sensors > - gc2235/gc0310/0v2680/ov2722/ov5693/mt9m114... > +Limitations: > > -2. To test the patches, you also need the ISP firmware > +1. To test the patches, you also need the ISP firmware > > for BYT:/lib/firmware/shisp_2400b0_v21.bin > for CHT:/lib/firmware/shisp_2401a0_v21.bin > @@ -51,14 +56,14 @@ Limitations: > device but can also be extracted from the upgrade kit if you've managed > to lose them somehow. > > -3. Without a 3A libary the capture behaviour is not very good. To take a good > +2. Without a 3A libary the capture behaviour is not very good. To take a good > picture, you need tune ISP parameters by IOCTL functions or use a 3A > libary > such as libxcam. > > -4. The driver is intended to drive the PCI exposed versions of the device. > +3. The driver is intended to drive the PCI exposed versions of the device. > It will not detect those devices enumerated via ACPI as a field of the > i915 GPU driver. > > -5. The driver supports only v2 of the IPU/Camera. It will not work with the > +4. The driver supports only v2 of the IPU/Camera. It will not work with the > versions of the hardware in other SoCs. > > -- > 2.7.4 > -- With Best Regards, Andy Shevchenko
[PATCH v1 08/13] staging: atomisp: Remove ->power_ctrl() callback
There is redundant callback which does nothing in upstreamed version of
the driver.
Remove it along with user call places.
Mostly done with help of coccinelle.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/staging/media/atomisp/i2c/gc0310.c | 4
drivers/staging/media/atomisp/i2c/gc2235.c | 4
drivers/staging/media/atomisp/i2c/mt9m114.c| 4
drivers/staging/media/atomisp/i2c/ov2680.c | 4
drivers/staging/media/atomisp/i2c/ov2722.c | 4
drivers/staging/media/atomisp/i2c/ov5693/ov5693.c | 4
drivers/staging/media/atomisp/i2c/ov8858.c | 4
drivers/staging/media/atomisp/include/linux/atomisp_platform.h | 8
8 files changed, 4 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/gc0310.c
b/drivers/staging/media/atomisp/i2c/gc0310.c
index 672a28c060f6..b6b1956293c0 100644
--- a/drivers/staging/media/atomisp/i2c/gc0310.c
+++ b/drivers/staging/media/atomisp/i2c/gc0310.c
@@ -737,10 +737,6 @@ static int power_ctrl(struct v4l2_subdev *sd, bool flag)
if (!dev || !dev->platform_data)
return -ENODEV;
- /* Non-gmin platforms use the legacy callback */
- if (dev->platform_data->power_ctrl)
- return dev->platform_data->power_ctrl(sd, flag);
-
if (flag) {
/* The upstream module driver (written to Crystal
* Cove) had this logic to pulse the rails low first.
diff --git a/drivers/staging/media/atomisp/i2c/gc2235.c
b/drivers/staging/media/atomisp/i2c/gc2235.c
index 81b23b55f73a..46e063dcdc19 100644
--- a/drivers/staging/media/atomisp/i2c/gc2235.c
+++ b/drivers/staging/media/atomisp/i2c/gc2235.c
@@ -547,10 +547,6 @@ static int power_ctrl(struct v4l2_subdev *sd, bool flag)
if (!dev || !dev->platform_data)
return -ENODEV;
- /* Non-gmin platforms use the legacy callback */
- if (dev->platform_data->power_ctrl)
- return dev->platform_data->power_ctrl(sd, flag);
-
if (flag) {
ret = dev->platform_data->v1p8_ctrl(sd, 1);
usleep_range(60, 90);
diff --git a/drivers/staging/media/atomisp/i2c/mt9m114.c
b/drivers/staging/media/atomisp/i2c/mt9m114.c
index 4968deae2525..950627efa977 100644
--- a/drivers/staging/media/atomisp/i2c/mt9m114.c
+++ b/drivers/staging/media/atomisp/i2c/mt9m114.c
@@ -454,10 +454,6 @@ static int power_ctrl(struct v4l2_subdev *sd, bool flag)
if (!dev || !dev->platform_data)
return -ENODEV;
- /* Non-gmin platforms use the legacy callback */
- if (dev->platform_data->power_ctrl)
- return dev->platform_data->power_ctrl(sd, flag);
-
if (flag) {
ret = dev->platform_data->v2p8_ctrl(sd, 1);
if (ret == 0) {
diff --git a/drivers/staging/media/atomisp/i2c/ov2680.c
b/drivers/staging/media/atomisp/i2c/ov2680.c
index 162150055770..9279246cf0b1 100644
--- a/drivers/staging/media/atomisp/i2c/ov2680.c
+++ b/drivers/staging/media/atomisp/i2c/ov2680.c
@@ -846,10 +846,6 @@ static int power_ctrl(struct v4l2_subdev *sd, bool flag)
if (!dev || !dev->platform_data)
return -ENODEV;
- /* Non-gmin platforms use the legacy callback */
- if (dev->platform_data->power_ctrl)
- return dev->platform_data->power_ctrl(sd, flag);
-
if (flag) {
ret |= dev->platform_data->v1p8_ctrl(sd, 1);
ret |= dev->platform_data->v2p8_ctrl(sd, 1);
diff --git a/drivers/staging/media/atomisp/i2c/ov2722.c
b/drivers/staging/media/atomisp/i2c/ov2722.c
index 6c1057542aea..39296a784162 100644
--- a/drivers/staging/media/atomisp/i2c/ov2722.c
+++ b/drivers/staging/media/atomisp/i2c/ov2722.c
@@ -650,10 +650,6 @@ static int power_ctrl(struct v4l2_subdev *sd, bool flag)
if (!dev || !dev->platform_data)
return -ENODEV;
- /* Non-gmin platforms use the legacy callback */
- if (dev->platform_data->power_ctrl)
- return dev->platform_data->power_ctrl(sd, flag);
-
if (flag) {
ret = dev->platform_data->v1p8_ctrl(sd, 1);
if (ret == 0) {
diff --git a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
index 8d5b4c3ea55d..33651ec0218f 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
+++ b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
@@ -1297,10 +1297,6 @@ static int power_ctrl(struct v4l2_subdev *sd, bool flag)
if (!dev || !dev->platform_data)
return -ENODEV;
- /* Non-gmin platforms use the legacy callback */
- if (dev->platform_data->power_ctrl)
-
[PATCH v1 07/13] staging: atomisp: Remove ->gpio_ctrl() callback
There is redundant callback which does nothing in upstreamed version of
the driver.
Remove it along with user call places.
Mostly done with help of coccinelle.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/staging/media/atomisp/i2c/gc0310.c | 4
drivers/staging/media/atomisp/i2c/gc2235.c | 4
drivers/staging/media/atomisp/i2c/mt9m114.c| 4
drivers/staging/media/atomisp/i2c/ov2680.c | 4
drivers/staging/media/atomisp/i2c/ov2722.c | 4
drivers/staging/media/atomisp/i2c/ov5693/ov5693.c | 4
drivers/staging/media/atomisp/i2c/ov8858.c | 4
drivers/staging/media/atomisp/include/linux/atomisp_platform.h | 2 --
8 files changed, 30 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/gc0310.c
b/drivers/staging/media/atomisp/i2c/gc0310.c
index 0e6fcf44b656..672a28c060f6 100644
--- a/drivers/staging/media/atomisp/i2c/gc0310.c
+++ b/drivers/staging/media/atomisp/i2c/gc0310.c
@@ -771,10 +771,6 @@ static int gpio_ctrl(struct v4l2_subdev *sd, bool flag)
if (!dev || !dev->platform_data)
return -ENODEV;
- /* Non-gmin platforms use the legacy callback */
- if (dev->platform_data->gpio_ctrl)
- return dev->platform_data->gpio_ctrl(sd, flag);
-
/* GPIO0 == "reset" (active low), GPIO1 == "power down" */
if (flag) {
/* Pulse reset, then release power down */
diff --git a/drivers/staging/media/atomisp/i2c/gc2235.c
b/drivers/staging/media/atomisp/i2c/gc2235.c
index 94b93ccc6aeb..81b23b55f73a 100644
--- a/drivers/staging/media/atomisp/i2c/gc2235.c
+++ b/drivers/staging/media/atomisp/i2c/gc2235.c
@@ -571,10 +571,6 @@ static int gpio_ctrl(struct v4l2_subdev *sd, bool flag)
if (!dev || !dev->platform_data)
return -ENODEV;
- /* Non-gmin platforms use the legacy callback */
- if (dev->platform_data->gpio_ctrl)
- return dev->platform_data->gpio_ctrl(sd, flag);
-
ret |= dev->platform_data->gpio1_ctrl(sd, !flag);
usleep_range(60, 90);
return dev->platform_data->gpio0_ctrl(sd, flag);
diff --git a/drivers/staging/media/atomisp/i2c/mt9m114.c
b/drivers/staging/media/atomisp/i2c/mt9m114.c
index 4ac1ad045283..4968deae2525 100644
--- a/drivers/staging/media/atomisp/i2c/mt9m114.c
+++ b/drivers/staging/media/atomisp/i2c/mt9m114.c
@@ -480,10 +480,6 @@ static int gpio_ctrl(struct v4l2_subdev *sd, bool flag)
if (!dev || !dev->platform_data)
return -ENODEV;
- /* Non-gmin platforms use the legacy callback */
- if (dev->platform_data->gpio_ctrl)
- return dev->platform_data->gpio_ctrl(sd, flag);
-
/* Note: current modules wire only one GPIO signal (RESET#),
* but the schematic wires up two to the connector. BIOS
* versions have been unfortunately inconsistent with which
diff --git a/drivers/staging/media/atomisp/i2c/ov2680.c
b/drivers/staging/media/atomisp/i2c/ov2680.c
index a42adeeb748c..162150055770 100644
--- a/drivers/staging/media/atomisp/i2c/ov2680.c
+++ b/drivers/staging/media/atomisp/i2c/ov2680.c
@@ -871,10 +871,6 @@ static int gpio_ctrl(struct v4l2_subdev *sd, bool flag)
if (!dev || !dev->platform_data)
return -ENODEV;
- /* Non-gmin platforms use the legacy callback */
- if (dev->platform_data->gpio_ctrl)
- return dev->platform_data->gpio_ctrl(sd, flag);
-
/* The OV2680 documents only one GPIO input (#XSHUTDN), but
* existing integrations often wire two (reset/power_down)
* because that is the way other sensors work. There is no
diff --git a/drivers/staging/media/atomisp/i2c/ov2722.c
b/drivers/staging/media/atomisp/i2c/ov2722.c
index 1b7012f47303..6c1057542aea 100644
--- a/drivers/staging/media/atomisp/i2c/ov2722.c
+++ b/drivers/staging/media/atomisp/i2c/ov2722.c
@@ -677,10 +677,6 @@ static int gpio_ctrl(struct v4l2_subdev *sd, bool flag)
if (!dev || !dev->platform_data)
return -ENODEV;
- /* Non-gmin platforms use the legacy callback */
- if (dev->platform_data->gpio_ctrl)
- return dev->platform_data->gpio_ctrl(sd, flag);
-
/* Note: the GPIO order is asymmetric: always RESET#
* before PWDN# when turning it on or off.
*/
diff --git a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
index 357821af4db0..8d5b4c3ea55d 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
+++ b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
@@ -1332,10 +1332,6 @@ static int gpio_ctrl(struct v4l2_subdev *sd, bool flag)
if (!dev || !dev->platform_data)
[PATCH v1 10/13] staging: atomisp: Remove Gmin dead code #1
struct camera_af_platform_data and bound functions are not used anywhere.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
.../media/atomisp/include/linux/atomisp_platform.h | 6 --
.../platform/intel-mid/atomisp_gmin_platform.c | 22 --
2 files changed, 28 deletions(-)
diff --git a/drivers/staging/media/atomisp/include/linux/atomisp_platform.h
b/drivers/staging/media/atomisp/include/linux/atomisp_platform.h
index a8c1825e1d0d..2dae4935ed75 100644
--- a/drivers/staging/media/atomisp/include/linux/atomisp_platform.h
+++ b/drivers/staging/media/atomisp/include/linux/atomisp_platform.h
@@ -221,12 +221,6 @@ struct camera_sensor_platform_data {
char *module_id);
};
-struct camera_af_platform_data {
- int (*power_ctrl)(struct v4l2_subdev *subdev, int flag);
-};
-
-const struct camera_af_platform_data *camera_get_af_platform_data(void);
-
struct camera_mipi_info {
enum atomisp_camera_portport;
unsigned intnum_lanes;
diff --git
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 3f7814a3a5a4..d9db0b13f506 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -126,28 +126,6 @@ static int af_power_ctrl(struct v4l2_subdev *subdev, int
flag)
return 0;
}
-/*
- * Used in a handful of modules. Focus motor control, I think. Note
- * that there is no configurability in the API, so this needs to be
- * fixed where it is used.
- *
- * struct camera_af_platform_data {
- * int (*power_ctrl)(struct v4l2_subdev *subdev, int flag);
- * };
- *
- * Note that the implementation in MCG platform_camera.c is stubbed
- * out anyway (i.e. returns zero from the callback) on BYT. So
- * neither needed on gmin platforms or supported upstream.
- */
-const struct camera_af_platform_data *camera_get_af_platform_data(void)
-{
- static struct camera_af_platform_data afpd = {
- .power_ctrl = af_power_ctrl,
- };
- return
-}
-EXPORT_SYMBOL_GPL(camera_get_af_platform_data);
-
int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
struct camera_sensor_platform_data *plat_data,
enum intel_v4l2_subdev_type type)
--
2.14.1
[PATCH v1 03/13] staging: atomisp: Use module_i2c_driver() macro
This is done using coccinelle semantic patch:
//
@a@
identifier f, x;
@@
-static f(...) { return i2c_add_driver(); }
@b depends on a@
identifier e, a.x;
@@
-static e(...) { i2c_del_driver(); }
@c depends on a && b@
identifier a.f;
declarer name module_init;
@@
-module_init(f);
@d depends on a && b && c@
identifier b.e, a.x;
declarer name module_exit;
declarer name module_i2c_driver;
@@
-module_exit(e);
+module_i2c_driver(x);
//
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/staging/media/atomisp/i2c/gc0310.c| 15 +--
drivers/staging/media/atomisp/i2c/gc2235.c| 15 +--
drivers/staging/media/atomisp/i2c/lm3554.c| 13 +
drivers/staging/media/atomisp/i2c/mt9m114.c | 14 +-
drivers/staging/media/atomisp/i2c/ov2680.c| 16 +---
drivers/staging/media/atomisp/i2c/ov2722.c| 15 +--
drivers/staging/media/atomisp/i2c/ov5693/ov5693.c | 15 +--
drivers/staging/media/atomisp/i2c/ov8858.c| 14 +-
8 files changed, 8 insertions(+), 109 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/gc0310.c
b/drivers/staging/media/atomisp/i2c/gc0310.c
index 35ed51ffe944..730fa5dd80f5 100644
--- a/drivers/staging/media/atomisp/i2c/gc0310.c
+++ b/drivers/staging/media/atomisp/i2c/gc0310.c
@@ -1470,20 +1470,7 @@ static struct i2c_driver gc0310_driver = {
.remove = gc0310_remove,
.id_table = gc0310_id,
};
-
-static int init_gc0310(void)
-{
- return i2c_add_driver(_driver);
-}
-
-static void exit_gc0310(void)
-{
-
- i2c_del_driver(_driver);
-}
-
-module_init(init_gc0310);
-module_exit(exit_gc0310);
+module_i2c_driver(gc0310_driver);
MODULE_AUTHOR("Lai, Angie <angie@intel.com>");
MODULE_DESCRIPTION("A low-level driver for GalaxyCore GC0310 sensors");
diff --git a/drivers/staging/media/atomisp/i2c/gc2235.c
b/drivers/staging/media/atomisp/i2c/gc2235.c
index e43d31ea9676..6d4a432b6bae 100644
--- a/drivers/staging/media/atomisp/i2c/gc2235.c
+++ b/drivers/staging/media/atomisp/i2c/gc2235.c
@@ -1199,20 +1199,7 @@ static struct i2c_driver gc2235_driver = {
.remove = gc2235_remove,
.id_table = gc2235_id,
};
-
-static int init_gc2235(void)
-{
- return i2c_add_driver(_driver);
-}
-
-static void exit_gc2235(void)
-{
-
- i2c_del_driver(_driver);
-}
-
-module_init(init_gc2235);
-module_exit(exit_gc2235);
+module_i2c_driver(gc2235_driver);
MODULE_AUTHOR("Shuguang Gong <shuguang.g...@intel.com>");
MODULE_DESCRIPTION("A low-level driver for GC2235 sensors");
diff --git a/drivers/staging/media/atomisp/i2c/lm3554.c
b/drivers/staging/media/atomisp/i2c/lm3554.c
index 679176f7c542..5424685eb447 100644
--- a/drivers/staging/media/atomisp/i2c/lm3554.c
+++ b/drivers/staging/media/atomisp/i2c/lm3554.c
@@ -991,19 +991,8 @@ static struct i2c_driver lm3554_driver = {
.remove = lm3554_remove,
.id_table = lm3554_id,
};
+module_i2c_driver(lm3554_driver);
-static __init int init_lm3554(void)
-{
- return i2c_add_driver(_driver);
-}
-
-static __exit void exit_lm3554(void)
-{
- i2c_del_driver(_driver);
-}
-
-module_init(init_lm3554);
-module_exit(exit_lm3554);
MODULE_AUTHOR("Jing Tao <jing@intel.com>");
MODULE_DESCRIPTION("LED flash driver for LM3554");
MODULE_LICENSE("GPL");
diff --git a/drivers/staging/media/atomisp/i2c/mt9m114.c
b/drivers/staging/media/atomisp/i2c/mt9m114.c
index 3c837cb8859c..14fe39f9feb6 100644
--- a/drivers/staging/media/atomisp/i2c/mt9m114.c
+++ b/drivers/staging/media/atomisp/i2c/mt9m114.c
@@ -1945,19 +1945,7 @@ static struct i2c_driver mt9m114_driver = {
.remove = mt9m114_remove,
.id_table = mt9m114_id,
};
-
-static __init int init_mt9m114(void)
-{
- return i2c_add_driver(_driver);
-}
-
-static __exit void exit_mt9m114(void)
-{
- i2c_del_driver(_driver);
-}
-
-module_init(init_mt9m114);
-module_exit(exit_mt9m114);
+module_i2c_driver(mt9m114_driver);
MODULE_AUTHOR("Shuguang Gong <shuguang.g...@intel.com>");
MODULE_LICENSE("GPL");
diff --git a/drivers/staging/media/atomisp/i2c/ov2680.c
b/drivers/staging/media/atomisp/i2c/ov2680.c
index 51b7d61df0f5..0dce3c03b2cd 100644
--- a/drivers/staging/media/atomisp/i2c/ov2680.c
+++ b/drivers/staging/media/atomisp/i2c/ov2680.c
@@ -1527,7 +1527,6 @@ MODULE_DEVICE_TABLE(acpi, ov2680_acpi_match);
MODULE_DEVICE_TABLE(i2c, ov2680_id);
static struct i2c_driver ov2680_driver = {
.driver = {
- .owner = THIS_MODULE,
.name = OV2680_NAME,
.acpi_match_table = ACPI_PTR(ov2680_acpi_match),
@@ -1536,20 +1535,7 @@ static struct i2c_driver ov2680_driver = {
.remove = ov2680_remove,
.id_table = ov2680_id,
};
-
-static int init_ov2680(void)
-{
- return i2c_add_dri
[PATCH v1 09/13] staging: atomisp: Remove unused members of camera_sensor_platform_data
Remove unused members along with dead code.
Mostly done with help of coccinelle.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/staging/media/atomisp/i2c/gc0310.c | 13 -
drivers/staging/media/atomisp/i2c/gc2235.c | 13 -
drivers/staging/media/atomisp/i2c/mt9m114.c | 9 -
drivers/staging/media/atomisp/i2c/ov2722.c | 13 -
drivers/staging/media/atomisp/i2c/ov8858.c | 13 -
.../staging/media/atomisp/include/linux/atomisp_platform.h | 5 -
drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 9 +
.../atomisp/platform/intel-mid/atomisp_gmin_platform.c | 12
8 files changed, 1 insertion(+), 86 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/gc0310.c
b/drivers/staging/media/atomisp/i2c/gc0310.c
index b6b1956293c0..0b32c8a94e5c 100644
--- a/drivers/staging/media/atomisp/i2c/gc0310.c
+++ b/drivers/staging/media/atomisp/i2c/gc0310.c
@@ -1156,13 +1156,6 @@ static int gc0310_s_config(struct v4l2_subdev *sd,
(struct camera_sensor_platform_data *)platform_data;
mutex_lock(>input_lock);
- if (dev->platform_data->platform_init) {
- ret = dev->platform_data->platform_init(client);
- if (ret) {
- dev_err(>dev, "platform init err\n");
- goto platform_init_failed;
- }
- }
/* power off the module, then power on it in future
* as first power on by board may not fulfill the
* power on sequqence needed by the module
@@ -1207,9 +1200,6 @@ static int gc0310_s_config(struct v4l2_subdev *sd,
power_down(sd);
dev_err(>dev, "sensor power-gating failed\n");
fail_power_off:
- if (dev->platform_data->platform_deinit)
- dev->platform_data->platform_deinit();
-platform_init_failed:
mutex_unlock(>input_lock);
return ret;
}
@@ -1353,9 +1343,6 @@ static int gc0310_remove(struct i2c_client *client)
struct gc0310_device *dev = to_gc0310_sensor(sd);
dev_dbg(>dev, "gc0310_remove...\n");
- if (dev->platform_data->platform_deinit)
- dev->platform_data->platform_deinit();
-
dev->platform_data->csi_cfg(sd, 0);
v4l2_device_unregister_subdev(sd);
diff --git a/drivers/staging/media/atomisp/i2c/gc2235.c
b/drivers/staging/media/atomisp/i2c/gc2235.c
index 46e063dcdc19..bcfcdc220803 100644
--- a/drivers/staging/media/atomisp/i2c/gc2235.c
+++ b/drivers/staging/media/atomisp/i2c/gc2235.c
@@ -897,13 +897,6 @@ static int gc2235_s_config(struct v4l2_subdev *sd,
(struct camera_sensor_platform_data *)platform_data;
mutex_lock(>input_lock);
- if (dev->platform_data->platform_init) {
- ret = dev->platform_data->platform_init(client);
- if (ret) {
- dev_err(>dev, "platform init err\n");
- goto platform_init_failed;
- }
- }
/* power off the module, then power on it in future
* as first power on by board may not fulfill the
* power on sequqence needed by the module
@@ -947,9 +940,6 @@ static int gc2235_s_config(struct v4l2_subdev *sd,
power_down(sd);
dev_err(>dev, "sensor power-gating failed\n");
fail_power_off:
- if (dev->platform_data->platform_deinit)
- dev->platform_data->platform_deinit();
-platform_init_failed:
mutex_unlock(>input_lock);
return ret;
}
@@ -1092,9 +1082,6 @@ static int gc2235_remove(struct i2c_client *client)
struct gc2235_device *dev = to_gc2235_sensor(sd);
dev_dbg(>dev, "gc2235_remove...\n");
- if (dev->platform_data->platform_deinit)
- dev->platform_data->platform_deinit();
-
dev->platform_data->csi_cfg(sd, 0);
v4l2_device_unregister_subdev(sd);
diff --git a/drivers/staging/media/atomisp/i2c/mt9m114.c
b/drivers/staging/media/atomisp/i2c/mt9m114.c
index 950627efa977..09018d5ccaf2 100644
--- a/drivers/staging/media/atomisp/i2c/mt9m114.c
+++ b/drivers/staging/media/atomisp/i2c/mt9m114.c
@@ -1575,13 +1575,6 @@ mt9m114_s_config(struct v4l2_subdev *sd, int irq, void
*platform_data)
dev->platform_data =
(struct camera_sensor_platform_data *)platform_data;
- if (dev->platform_data->platform_init) {
- ret = dev->platform_data->platform_init(client);
- if (ret) {
- v4l2_err(client, "mt9m114 platform init err\n");
- return ret;
- }
- }
ret = power_up(sd);
if (ret) {
[PATCH v1 02/13] staging: atomisp: Remove AP1302 sensor support
This sensor is not used by any known ACPI-enabled platform
(and no kernel users for it so far).
Just remove it for good until we get a platform which actually uses it.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/staging/media/atomisp/i2c/Kconfig | 12 -
drivers/staging/media/atomisp/i2c/Makefile |2 -
drivers/staging/media/atomisp/i2c/ap1302.c | 1255
drivers/staging/media/atomisp/i2c/ap1302.h | 198 -
4 files changed, 1467 deletions(-)
delete mode 100644 drivers/staging/media/atomisp/i2c/ap1302.c
delete mode 100644 drivers/staging/media/atomisp/i2c/ap1302.h
diff --git a/drivers/staging/media/atomisp/i2c/Kconfig
b/drivers/staging/media/atomisp/i2c/Kconfig
index b607c9837e2f..4da028d919c5 100644
--- a/drivers/staging/media/atomisp/i2c/Kconfig
+++ b/drivers/staging/media/atomisp/i2c/Kconfig
@@ -58,18 +58,6 @@ config VIDEO_MT9M114
It currently only works with the atomisp driver.
-config VIDEO_AP1302
- tristate "AP1302 external ISP support"
- depends on I2C && VIDEO_V4L2
- select REGMAP_I2C
- ---help---
-This is a Video4Linux2 sensor-level driver for the external
-ISP AP1302.
-
-AP1302 is an exteral ISP.
-
-It currently only works with the atomisp driver.
-
config VIDEO_GC0310
tristate "GC0310 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/staging/media/atomisp/i2c/Makefile
b/drivers/staging/media/atomisp/i2c/Makefile
index 8a5a37467c3e..09331f661791 100644
--- a/drivers/staging/media/atomisp/i2c/Makefile
+++ b/drivers/staging/media/atomisp/i2c/Makefile
@@ -11,8 +11,6 @@ obj-$(CONFIG_VIDEO_GC0310) += gc0310.o
obj-$(CONFIG_VIDEO_MSRLIST_HELPER) += libmsrlisthelper.o
-obj-$(CONFIG_VIDEO_AP1302) += ap1302.o
-
# Makefile for flash drivers
#
diff --git a/drivers/staging/media/atomisp/i2c/ap1302.c
b/drivers/staging/media/atomisp/i2c/ap1302.c
deleted file mode 100644
index 2f772a020c8b..
--- a/drivers/staging/media/atomisp/i2c/ap1302.c
+++ /dev/null
@@ -1,1255 +0,0 @@
-/*
- *
- * Copyright (c) 2013 Intel Corporation. All Rights Reserved.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License version
- * 2 as published by the Free Software Foundation.
- *
- * 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.
- *
- */
-
-#include "../include/linux/atomisp.h"
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include "ap1302.h"
-
-#define to_ap1302_device(sub_dev) \
- container_of(sub_dev, struct ap1302_device, sd)
-
-/* Static definitions */
-static struct regmap_config ap1302_reg16_config = {
- .reg_bits = 16,
- .val_bits = 16,
- .reg_format_endian = REGMAP_ENDIAN_BIG,
- .val_format_endian = REGMAP_ENDIAN_BIG,
-};
-
-static struct regmap_config ap1302_reg32_config = {
- .reg_bits = 16,
- .val_bits = 32,
- .reg_format_endian = REGMAP_ENDIAN_BIG,
- .val_format_endian = REGMAP_ENDIAN_BIG,
-};
-
-static enum ap1302_contexts ap1302_cntx_mapping[] = {
- CONTEXT_PREVIEW,/* Invalid atomisp run mode */
- CONTEXT_VIDEO, /* ATOMISP_RUN_MODE_VIDEO */
- CONTEXT_SNAPSHOT, /* ATOMISP_RUN_MODE_STILL_CAPTURE */
- CONTEXT_SNAPSHOT, /* ATOMISP_RUN_MODE_CONTINUOUS_CAPTURE */
- CONTEXT_PREVIEW,/* ATOMISP_RUN_MODE_PREVIEW */
-};
-
-static struct ap1302_res_struct ap1302_preview_res[] = {
- {
- .width = 640,
- .height = 480,
- .fps = 30,
- },
- {
- .width = 720,
- .height = 480,
- .fps = 30,
- },
- {
- .width = 1280,
- .height = 720,
- .fps = 30,
- },
- {
- .width = 1920,
- .height = 1080,
- .fps = 30,
- }
-};
-
-static struct ap1302_res_struct ap1302_snapshot_res[] = {
- {
- .width = 640,
- .height = 480,
- .fps = 30,
- },
- {
- .width = 720,
- .height = 480,
- .fps = 30,
- },
- {
- .width = 1280,
- .height = 720,
- .fps = 30,
- },
- {
- .width = 1920,
- .height = 1080,
- .fps = 30,
- }
-};
-
-static struct ap1302_res_struct ap1302_video_res[] = {
- {
- .width = 640,
- .height = 480,
- .fps = 30,
- },
- {
- .width =
[PATCH v1 13/13] staging: atomisp: Remove FSF snail address
Snail address is subject to change, remove it completely from the code. This has been done using the following script: sed -i '/You should/,/02110-1301/d' \ $(git grep -n -w Franklin -- drivers/staging/media/atomisp/ | cut -f1 -d:) No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> --- drivers/staging/media/atomisp/i2c/gc0310.h| 4 drivers/staging/media/atomisp/i2c/libmsrlisthelper.c | 4 drivers/staging/media/atomisp/i2c/lm3554.c| 4 drivers/staging/media/atomisp/i2c/mt9m114.c | 4 drivers/staging/media/atomisp/i2c/mt9m114.h | 4 drivers/staging/media/atomisp/i2c/ov2680.h| 4 drivers/staging/media/atomisp/i2c/ov2722.h| 4 drivers/staging/media/atomisp/i2c/ov5693/ad5823.h | 4 drivers/staging/media/atomisp/i2c/ov5693/ov5693.c | 4 drivers/staging/media/atomisp/i2c/ov5693/ov5693.h | 4 drivers/staging/media/atomisp/i2c/ov8858.c| 4 drivers/staging/media/atomisp/i2c/ov8858.h| 4 drivers/staging/media/atomisp/i2c/ov8858_btns.h | 4 drivers/staging/media/atomisp/include/linux/atomisp.h | 4 drivers/staging/media/atomisp/include/linux/atomisp_platform.h| 4 drivers/staging/media/atomisp/include/linux/libmsrlisthelper.h| 4 drivers/staging/media/atomisp/include/media/lm3554.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp-regs.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_acc.c | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_acc.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_common.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_csi2.c | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_csi2.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_dfs_tables.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c| 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.h| 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_file.c | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_file.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_helper.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c| 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.h| 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_tables.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_trace_event.h | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 4 drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.h | 4 drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c | 4 drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c | 4 drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_dynamic_pool.c | 4 drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_reserved_pool.c| 4 drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_vm.c | 4 .../media/atomisp/pci/atomisp2/hrt/hive_isp_css_custom_host_hrt.h | 4 drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c | 4 drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.h | 4 drivers/staging/media/atomisp/pci/atomisp2/include/hmm/hmm.h
[PATCH v1 11/13] staging: atomisp: Remove Gmin dead code #2
media/lm3642.h is not used anywhere. Moreover, there is a driver under
LEDs framework for very same IP which would be used anyway.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
.../staging/media/atomisp/include/media/lm3642.h | 153 -
1 file changed, 153 deletions(-)
delete mode 100644 drivers/staging/media/atomisp/include/media/lm3642.h
diff --git a/drivers/staging/media/atomisp/include/media/lm3642.h
b/drivers/staging/media/atomisp/include/media/lm3642.h
deleted file mode 100644
index 545d95763335..
--- a/drivers/staging/media/atomisp/include/media/lm3642.h
+++ /dev/null
@@ -1,153 +0,0 @@
-/*
- * include/media/lm3642.h
- *
- * Copyright (c) 2010-2012 Intel Corporation. All Rights Reserved.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License version
- * 2 as published by the Free Software Foundation.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.
- */
-
-#ifndef _LM3642_H_
-#define _LM3642_H_
-
-#include
-#include
-
-#define LM3642_NAME"lm3642"
-#define LM3642_ID 3642
-
-#definev4l2_queryctrl_entry_integer(_id, _name,\
- _minimum, _maximum, _step, \
- _default_value, _flags) \
- {\
- .id = (_id), \
- .type = V4L2_CTRL_TYPE_INTEGER, \
- .name = _name, \
- .minimum = (_minimum), \
- .maximum = (_maximum), \
- .step = (_step), \
- .default_value = (_default_value),\
- .flags = (_flags),\
- }
-#definev4l2_queryctrl_entry_boolean(_id, _name,\
- _default_value, _flags) \
- {\
- .id = (_id), \
- .type = V4L2_CTRL_TYPE_BOOLEAN, \
- .name = _name, \
- .minimum = 0, \
- .maximum = 1, \
- .step = 1, \
- .default_value = (_default_value),\
- .flags = (_flags),\
- }
-
-#defines_ctrl_id_entry_integer(_id, _name, \
- _minimum, _maximum, _step, \
- _default_value, _flags, \
- _s_ctrl, _g_ctrl) \
- {\
- .qc = v4l2_queryctrl_entry_integer(_id, _name,\
- _minimum, _maximum, _step,\
- _default_value, _flags), \
- .s_ctrl = _s_ctrl, \
- .g_ctrl = _g_ctrl, \
- }
-
-#defines_ctrl_id_entry_boolean(_id, _name, \
- _default_value, _flags, \
- _s_ctrl, _g_ctrl) \
- {\
- .qc = v4l2_queryctrl_entry_boolean(_id, _name,\
- _default_value, _flags), \
- .s_ctrl = _s_ctrl, \
- .g_ctrl = _g_ctrl, \
- }
-
-
-/* Default Values */
-#define LM3642_DEFAULT_TIMEOUT 300U
-#define LM3642_DEFAULT_RAMP_TIME0x10 /* 1.024ms */
-#define LM3642_DEFAULT_INDICATOR_CURRENT 0x01 /* 1.88A */
-#define LM3642_DEFAULT_FLASH_CURRENT0x0f /* 1500mA */
-
-/* Value settings for Flash Time-out Duration*/
-#define LM3642_MIN_TIMEOUT 100U
-#define LM3642_MAX_TIMEOUT 800U
-#define LM3642_TIMEOUT_STEPSIZE 100U
-
-/* Flash modes */
-#define LM3642_MODE_SHUTDOWN0
-#define LM3642_MODE_INDICATOR 1
-#define LM3642_MODE_TORCH 2
-#define LM3642_MODE_FLASH 3
-
-/* timer delay time */
-#define LM3642_TIMER_DELAY 5
-
-/* Percentage <-> value macros */
-#define LM3642_MIN_PERCENT 0U
-#define LM3642_MAX_PERCENT 100U
-#define LM3642_CLAMP_PERCENTAGE(val) \
- clamp(val, LM3642_MIN_PERCENT, LM3642_MAX_PERCENT)
-
-#define LM3642_VALUE_TO_PERCENT(v, step) \
- (unsigned long)((v)+1))*(step))+50)/100)
-#define LM3642_PERCENT_TO_VALUE(p, step) \
- (unsigned long)(p))*100)+((step)>>1))/(step)-1)
-
-/* Product specific limits
- * TODO: get these from platform data */
-#define LM3642_FLASH_MAX_LVL 0x0F /* 1500mA */
-#define LM3642_TORCH_MAX_LVL 0x07 /* 187mA */
-#define LM3642_INDICATOR_MAX_LVL 0x01 /* 1.88A */
-
-/* Flash brightness, input is percentage, output is [0..15] */
-#define LM3642_FLASH_STEP \
- ((100ul*(LM3642_MAX_PERCENT) \
- +((LM3642_FLASH_MAX_LVL+1)>>1)) \
- /((LM3642_FLASH_MAX_LVL+1)))
-#define LM3642_FLASH_DEFAULT_BRIGHTNESS \
- LM3642_VALUE_TO_PERCENT(15, LM3642_FLASH_STEP)
-
-/* Torch brightness, input is percentage, output is [0..7] */
-#define LM3642_TORCH_STEP \
-
[PATCH v1 12/13] staging: atomisp: Remove duplicate declaration in header
There are 3 declarations that are present in atomisp_platform.h and atomisp_gmin_platform.h. Remove duplications from the latter. Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> --- drivers/staging/media/atomisp/include/linux/atomisp_gmin_platform.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/staging/media/atomisp/include/linux/atomisp_gmin_platform.h b/drivers/staging/media/atomisp/include/linux/atomisp_gmin_platform.h index 5390b97ac6e7..7e3ca12dd4e9 100644 --- a/drivers/staging/media/atomisp/include/linux/atomisp_gmin_platform.h +++ b/drivers/staging/media/atomisp/include/linux/atomisp_gmin_platform.h @@ -17,9 +17,6 @@ #include "atomisp_platform.h" -const struct atomisp_camera_caps *atomisp_get_default_camera_caps(void); -const struct atomisp_platform_data *atomisp_get_platform_data(void); -const struct camera_af_platform_data *camera_get_af_platform_data(void); int atomisp_register_i2c_module(struct v4l2_subdev *subdev, struct camera_sensor_platform_data *plat_data, enum intel_v4l2_subdev_type type); -- 2.14.1
[PATCH v1 00/13] staging: atomisp: clean up bomb
The driver has been submitted with a limitation to few platforms and sensors which it does support. Even though two sensor drivers have no users neither on ACPI-enabled platforms, nor in current Linux kernel code. Patches 1 and 2 removes those drivers for now. It seems new contributors follow cargo cult programming done by the original driver developers. It's neither good for code, nor for reviewing process. To avoid such issues in the future here are few clean up patches, i.e. patches 3, 4, 6. 13. On top of this here are clean ups with regard to GPIO use. One may consider this as an intermediate clean up. This part toughly related to removal of unused sensor drivers in patches 1 and 2. Patch series has been partially compile tested. It would be nice to see someone with hardware to confirm it doesn't break anything. Andy Shevchenko (13): staging: atomisp: Remove IMX sensor support staging: atomisp: Remove AP1302 sensor support staging: atomisp: Use module_i2c_driver() macro staging: atomisp: Switch i2c drivers to use ->probe_new() staging: atomisp: Do not set GPIO twice staging: atomisp: Remove unneeded gpio.h inclusion staging: atomisp: Remove ->gpio_ctrl() callback staging: atomisp: Remove ->power_ctrl() callback staging: atomisp: Remove unused members of camera_sensor_platform_data staging: atomisp: Remove Gmin dead code #1 staging: atomisp: Remove Gmin dead code #2 staging: atomisp: Remove duplicate declaration in header staging: atomisp: Remove FSF snail address drivers/staging/media/atomisp/i2c/Kconfig | 22 +- drivers/staging/media/atomisp/i2c/Makefile |3 - drivers/staging/media/atomisp/i2c/ap1302.c | 1255 drivers/staging/media/atomisp/i2c/ap1302.h | 198 -- drivers/staging/media/atomisp/i2c/gc0310.c | 49 +- drivers/staging/media/atomisp/i2c/gc0310.h | 11 - drivers/staging/media/atomisp/i2c/gc2235.c | 50 +- drivers/staging/media/atomisp/i2c/gc2235.h |7 - drivers/staging/media/atomisp/i2c/imx/Kconfig |9 - drivers/staging/media/atomisp/i2c/imx/Makefile | 13 - drivers/staging/media/atomisp/i2c/imx/ad5816g.c| 216 -- drivers/staging/media/atomisp/i2c/imx/ad5816g.h| 49 - drivers/staging/media/atomisp/i2c/imx/common.h | 65 - drivers/staging/media/atomisp/i2c/imx/drv201.c | 208 -- drivers/staging/media/atomisp/i2c/imx/drv201.h | 38 - drivers/staging/media/atomisp/i2c/imx/dw9714.c | 222 -- drivers/staging/media/atomisp/i2c/imx/dw9714.h | 63 - drivers/staging/media/atomisp/i2c/imx/dw9718.c | 233 -- drivers/staging/media/atomisp/i2c/imx/dw9718.h | 64 - drivers/staging/media/atomisp/i2c/imx/dw9719.c | 198 -- drivers/staging/media/atomisp/i2c/imx/dw9719.h | 58 - drivers/staging/media/atomisp/i2c/imx/imx.c| 2479 -- drivers/staging/media/atomisp/i2c/imx/imx.h| 737 - drivers/staging/media/atomisp/i2c/imx/imx132.h | 566 drivers/staging/media/atomisp/i2c/imx/imx134.h | 2464 -- drivers/staging/media/atomisp/i2c/imx/imx135.h | 3374 drivers/staging/media/atomisp/i2c/imx/imx175.h | 1959 drivers/staging/media/atomisp/i2c/imx/imx208.h | 550 drivers/staging/media/atomisp/i2c/imx/imx219.h | 227 -- drivers/staging/media/atomisp/i2c/imx/imx227.h | 726 - drivers/staging/media/atomisp/i2c/imx/otp.c| 39 - .../media/atomisp/i2c/imx/otp_brcc064_e2prom.c | 80 - drivers/staging/media/atomisp/i2c/imx/otp_e2prom.c | 89 - drivers/staging/media/atomisp/i2c/imx/otp_imx.c| 190 -- drivers/staging/media/atomisp/i2c/imx/vcm.c| 45 - .../staging/media/atomisp/i2c/libmsrlisthelper.c |4 - drivers/staging/media/atomisp/i2c/lm3554.c | 35 +- drivers/staging/media/atomisp/i2c/mt9m114.c| 47 +- drivers/staging/media/atomisp/i2c/mt9m114.h|9 - drivers/staging/media/atomisp/i2c/ov2680.c | 39 +- drivers/staging/media/atomisp/i2c/ov2680.h | 14 - drivers/staging/media/atomisp/i2c/ov2722.c | 50 +- drivers/staging/media/atomisp/i2c/ov2722.h | 11 - drivers/staging/media/atomisp/i2c/ov5693/Kconfig |2 +- drivers/staging/media/atomisp/i2c/ov5693/ad5823.h |4 - drivers/staging/media/atomisp/i2c/ov5693/ov5693.c | 40 +- drivers/staging/media/atomisp/i2c/ov5693/ov5693.h | 11 - drivers/staging/media/atomisp/i2c/ov8858.c | 59 +- drivers/staging/media/atomisp/i2c/ov8858.h |5 - drivers/staging/media/atomisp/i2c/ov8858_btns.h|5 - .../staging/media/atomisp/include/linux/atomisp.h |4 - .../atomisp/include/linux/atomisp_gmin_platform.h |3 - .../media/atomisp/include/linux/atomisp_platform.h | 25 +- .../media/atomisp/include/linux/libmsrlisthelper.h |4 - .../staging/media/atomisp/include/media/lm3554.h |5 - .../stag
[PATCH v1 06/13] staging: atomisp: Remove unneeded gpio.h inclusion
GPIO handling is done only in two modules, the rest do not need to include linux/gpio.h header. Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> --- drivers/staging/media/atomisp/i2c/gc0310.c| 1 - drivers/staging/media/atomisp/i2c/gc2235.c| 1 - drivers/staging/media/atomisp/i2c/mt9m114.c | 1 - drivers/staging/media/atomisp/i2c/ov2680.c| 1 - drivers/staging/media/atomisp/i2c/ov2722.c| 1 - drivers/staging/media/atomisp/i2c/ov5693/ov5693.c | 1 - 6 files changed, 6 deletions(-) diff --git a/drivers/staging/media/atomisp/i2c/gc0310.c b/drivers/staging/media/atomisp/i2c/gc0310.c index 6f54304f1ca0..0e6fcf44b656 100644 --- a/drivers/staging/media/atomisp/i2c/gc0310.c +++ b/drivers/staging/media/atomisp/i2c/gc0310.c @@ -26,7 +26,6 @@ #include #include #include -#include #include #include #include diff --git a/drivers/staging/media/atomisp/i2c/gc2235.c b/drivers/staging/media/atomisp/i2c/gc2235.c index 8ed12e16caf4..94b93ccc6aeb 100644 --- a/drivers/staging/media/atomisp/i2c/gc2235.c +++ b/drivers/staging/media/atomisp/i2c/gc2235.c @@ -26,7 +26,6 @@ #include #include #include -#include #include #include #include "../include/linux/atomisp_gmin_platform.h" diff --git a/drivers/staging/media/atomisp/i2c/mt9m114.c b/drivers/staging/media/atomisp/i2c/mt9m114.c index 8c75372782d8..4ac1ad045283 100644 --- a/drivers/staging/media/atomisp/i2c/mt9m114.c +++ b/drivers/staging/media/atomisp/i2c/mt9m114.c @@ -32,7 +32,6 @@ #include #include #include -#include #include #include "../include/linux/atomisp_gmin_platform.h" #include diff --git a/drivers/staging/media/atomisp/i2c/ov2680.c b/drivers/staging/media/atomisp/i2c/ov2680.c index 99c6d699f899..a42adeeb748c 100644 --- a/drivers/staging/media/atomisp/i2c/ov2680.c +++ b/drivers/staging/media/atomisp/i2c/ov2680.c @@ -26,7 +26,6 @@ #include #include #include -#include #include #include #include diff --git a/drivers/staging/media/atomisp/i2c/ov2722.c b/drivers/staging/media/atomisp/i2c/ov2722.c index 2481fda345c0..1b7012f47303 100644 --- a/drivers/staging/media/atomisp/i2c/ov2722.c +++ b/drivers/staging/media/atomisp/i2c/ov2722.c @@ -26,7 +26,6 @@ #include #include #include -#include #include #include #include "../include/linux/atomisp_gmin_platform.h" diff --git a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c index a083c61ad3ea..357821af4db0 100644 --- a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c +++ b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c @@ -31,7 +31,6 @@ #include #include #include -#include #include #include #include -- 2.14.1
[PATCH v1 04/13] staging: atomisp: Switch i2c drivers to use ->probe_new()
Since most of the drivers are being used on ACPI enabled platforms
there is no need to keep legacy API support for them. Thus, switch
to ->probe_new() callback and remove orphaned code.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/staging/media/atomisp/i2c/Kconfig| 9 +++--
drivers/staging/media/atomisp/i2c/gc0310.c | 12
drivers/staging/media/atomisp/i2c/gc0310.h | 7 ---
drivers/staging/media/atomisp/i2c/gc2235.c | 13 +
drivers/staging/media/atomisp/i2c/gc2235.h | 7 ---
drivers/staging/media/atomisp/i2c/lm3554.c | 18 --
drivers/staging/media/atomisp/i2c/mt9m114.c | 11 +++
drivers/staging/media/atomisp/i2c/mt9m114.h | 5 -
drivers/staging/media/atomisp/i2c/ov2680.c | 14 --
drivers/staging/media/atomisp/i2c/ov2680.h | 10 --
drivers/staging/media/atomisp/i2c/ov2722.c | 13 -
drivers/staging/media/atomisp/i2c/ov2722.h | 7 ---
drivers/staging/media/atomisp/i2c/ov5693/Kconfig | 2 +-
drivers/staging/media/atomisp/i2c/ov5693/ov5693.c| 12
drivers/staging/media/atomisp/i2c/ov5693/ov5693.h| 7 ---
drivers/staging/media/atomisp/i2c/ov8858.c | 20 +---
drivers/staging/media/atomisp/i2c/ov8858.h | 1 -
drivers/staging/media/atomisp/i2c/ov8858_btns.h | 1 -
drivers/staging/media/atomisp/include/media/lm3554.h | 1 -
19 files changed, 41 insertions(+), 129 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/Kconfig
b/drivers/staging/media/atomisp/i2c/Kconfig
index 4da028d919c5..74bd45e54d69 100644
--- a/drivers/staging/media/atomisp/i2c/Kconfig
+++ b/drivers/staging/media/atomisp/i2c/Kconfig
@@ -6,6 +6,7 @@ source "drivers/staging/media/atomisp/i2c/ov5693/Kconfig"
config VIDEO_OV2722
tristate "OVT ov2722 sensor support"
+ depends on ACPI
depends on I2C && VIDEO_V4L2
---help---
This is a Video4Linux2 sensor-level driver for the OVT
@@ -17,6 +18,7 @@ config VIDEO_OV2722
config VIDEO_GC2235
tristate "Galaxy gc2235 sensor support"
+ depends on ACPI
depends on I2C && VIDEO_V4L2
---help---
This is a Video4Linux2 sensor-level driver for the OVT
@@ -28,6 +30,7 @@ config VIDEO_GC2235
config VIDEO_OV8858
tristate "Omnivision ov8858 sensor support"
+ depends on ACPI
depends on I2C && VIDEO_V4L2 && VIDEO_ATOMISP
---help---
This is a Video4Linux2 sensor-level driver for the Omnivision
@@ -49,6 +52,7 @@ config VIDEO_MSRLIST_HELPER
config VIDEO_MT9M114
tristate "Aptina mt9m114 sensor support"
+ depends on ACPI
depends on I2C && VIDEO_V4L2
---help---
This is a Video4Linux2 sensor-level driver for the Micron
@@ -60,6 +64,7 @@ config VIDEO_MT9M114
config VIDEO_GC0310
tristate "GC0310 sensor support"
+ depends on ACPI
depends on I2C && VIDEO_V4L2
---help---
This is a Video4Linux2 sensor-level driver for the Galaxycore
@@ -67,6 +72,7 @@ config VIDEO_GC0310
config VIDEO_OV2680
tristate "Omnivision OV2680 sensor support"
+ depends on ACPI
depends on I2C && VIDEO_V4L2
---help---
This is a Video4Linux2 sensor-level driver for the Omnivision
@@ -82,6 +88,7 @@ config VIDEO_OV2680
config VIDEO_LM3554
tristate "LM3554 flash light driver"
+ depends on ACPI
depends on VIDEO_V4L2 && I2C
---help---
This is a Video4Linux2 sub-dev driver for the LM3554
@@ -89,5 +96,3 @@ config VIDEO_LM3554
To compile this driver as a module, choose M here: the
module will be called lm3554
-
-
diff --git a/drivers/staging/media/atomisp/i2c/gc0310.c
b/drivers/staging/media/atomisp/i2c/gc0310.c
index 730fa5dd80f5..6f54304f1ca0 100644
--- a/drivers/staging/media/atomisp/i2c/gc0310.c
+++ b/drivers/staging/media/atomisp/i2c/gc0310.c
@@ -1375,8 +1375,7 @@ static int gc0310_remove(struct i2c_client *client)
return 0;
}
-static int gc0310_probe(struct i2c_client *client,
- const struct i2c_device_id *id)
+static int gc0310_probe(struct i2c_client *client)
{
struct gc0310_device *dev;
int ret;
@@ -1457,18 +1456,15 @@ static const struct acpi_device_id gc0310_acpi_match[]
= {
{"INT0310"},
{},
};
-
MODULE_DEVICE_TABLE(acpi, gc0310_acpi_match);
-MODULE_DEVICE_TABLE(i2c, gc0310_id);
static struct i2c_driver gc0310_driver = {
.driver = {
- .name = GC0310_NAME,
- .acpi_match_table = ACPI_PTR(gc0310_acpi_match),
+ .name = "gc03
[PATCH v1 05/13] staging: atomisp: Do not set GPIO twice
gpiod_get() configures GPIO line at the time of successful request.
Thus, no need to do this explicitly.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
.../atomisp/platform/intel-mid/atomisp_gmin_platform.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 17b4cfae5abf..0c5d09bdb93a 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -408,21 +408,11 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
if (!ret)
clk_disable_unprepare(gmin_subdevs[i].pmc_clk);
- if (!IS_ERR(gmin_subdevs[i].gpio0)) {
- ret = gpiod_direction_output(gmin_subdevs[i].gpio0, 0);
- if (ret)
- dev_err(dev, "gpio0 set output failed: %d\n", ret);
- } else {
+ if (IS_ERR(gmin_subdevs[i].gpio0))
gmin_subdevs[i].gpio0 = NULL;
- }
- if (!IS_ERR(gmin_subdevs[i].gpio1)) {
- ret = gpiod_direction_output(gmin_subdevs[i].gpio1, 0);
- if (ret)
- dev_err(dev, "gpio1 set output failed: %d\n", ret);
- } else {
+ if (IS_ERR(gmin_subdevs[i].gpio1))
gmin_subdevs[i].gpio1 = NULL;
- }
if (pmic_id == PMIC_REGULATOR) {
gmin_subdevs[i].v1p8_reg = regulator_get(dev, "V1P8SX");
--
2.14.1
Re: [PATCH v2] staging: atomisp: add a driver for ov5648 camera sensor
ratio < (int)8192) || (h_ratio < (int)8192) ||
> + (match > LARGEST_ALLOWED_RATIO_MISMATCH))
> + return -1;
Why (int) casting here and above?!
> +
> + return w_ratio + h_ratio;
> +}
> +
> +/* Return the nearest higher resolution index */
> +static int nearest_resolution_index(int w, int h)
> +{
> + int i;
> + int idx = -1;
> + int dist;
> + int min_dist = INT_MAX;
> + struct ov5648_resolution *tmp_res = NULL;
Reversed xmas tree order.
> +
> + for (i = 0; i < N_RES; i++) {
> + tmp_res = _res[i];
> + dist = distance(tmp_res, w, h);
> + if (dist == -1)
> + continue;
> + if (dist < min_dist) {
> + min_dist = dist;
> + idx = i;
> + }
> + }
> +
> + return idx;
> +}
>
> + id = u16) high) << 8) | (u16) low);
Redundant parens. Please, check all lines to avoid such.
> +
>
> + revision = (u8) high & 0x0f;
> +
> + dev_dbg(>dev, "sensor_revision = 0x%x\n", revision);
> + dev_dbg(>dev, "detect ov5648 success\n");
It would be one line, moreover, instead of above, you may use
...("...%c...", hex_asc_lo[high]);
> + return 0;
> +}
> +
> +static int ov5648_s_stream(struct v4l2_subdev *sd, int enable)
> +{
> + struct ov5648_device *dev = to_ov5648_sensor(sd);
> + struct i2c_client *client = v4l2_get_subdevdata(sd);
> + int ret;
+ empty line.
Please check all functions.
> + dev_dbg(>dev, "@%s:\n", __func__);
Noise. Remove.
Do this for all similar cases.
> + mutex_lock(>input_lock);
> +
> + ret = ov5648_write_reg(client, OV5648_8BIT, OV5648_SW_STREAM,
> + enable ? OV5648_START_STREAMING :
> + OV5648_STOP_STREAMING);
> +
> + mutex_unlock(>input_lock);
> +
> + return ret;
> +}
> +static int ov5648_remove(struct i2c_client *client)
> +{
> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> + struct ov5648_device *dev = to_ov5648_sensor(sd);
> + dev_dbg(>dev, "ov5648_remove...\n");
Noise, remove.
> +
> + dev->platform_data->csi_cfg(sd, 0);
> +
> + v4l2_device_unregister_subdev(sd);
> + media_entity_cleanup(>sd.entity);
> + v4l2_ctrl_handler_free(>ctrl_handler);
> + kfree(dev);
> +
> + return 0;
> +}
> +
> +static int ov5648_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct ov5648_device *dev;
> + size_t len = CAMERA_MODULE_ID_LEN * sizeof(char);
> + int ret;
> + void *pdata;
> + unsigned int i;
> +
> + dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> + if (!dev) {
> + dev_err(>dev, "out of memory\n");
> + return -ENOMEM;
> + }
> +
> + dev->camera_module = kzalloc(len, GFP_KERNEL);
> + if (!dev->camera_module) {
> + kfree(dev);
> + dev_err(>dev, "out of memory\n");
> + return -ENOMEM;
> + }
> +
> + mutex_init(>input_lock);
> +
> + dev->fmt_idx = 0;
> + //otp functions
Wrong style, noisy comment. Remove.
> + dev->current_otp.otp_en = 1;// enable otp functions
Ditto.
> + v4l2_i2c_subdev_init(&(dev->sd), client, _ops);
> +
> + if (gmin_get_config_var(>dev, "CameraModule",
> + dev->camera_module, )) {
> + kfree(dev->camera_module);
> + dev->camera_module = NULL;
> + dev_info(>dev, "Camera module id is
> missing\n");
> + }
> +
> + if (ACPI_COMPANION(>dev))
> + pdata = gmin_camera_platform_data(>sd,
> + ATOMISP_INPUT_FORMA
> T_RAW_10,
> + atomisp_bayer_order
> _bggr);
> + else
> + pdata = client->dev.platform_data;
What kind of platforms will use platform_data?
> +out_free:
> + v4l2_device_unregister_subdev(>sd);
Doesn't v4l2 have devm_*() helpers?
> + kfree(dev->camera_module);
> + kfree(dev);
Shouldn't those be devm_kzalloc() ?
> + return ret;
> +}
> +
> +static const struct acpi_device_id ov5648_acpi_match[] = {
> + {"XXOV5648"},
WTF is that?
> + {"INT5648"},
> + {},
> +};
> +MODULE_DEVICE_TABLE(acpi, ov5648_acpi_match);
> +
> +MODULE_DEVICE_TABLE(i2c, ov5648_id);
Where is the table?
> +static struct i2c_driver ov5648_driver = {
> + .driver = {
> + .owner = THIS_MODULE,
Redundant.
> + .name = OV5648_NAME,
> + .acpi_match_table = ACPI_PTR(ov5648_acpi_match),
> + },
> + .probe = ov5648_probe,
> + .remove = ov5648_remove,
> + .id_table = ov5648_id,
> +};
> +
> +static int init_ov5648(void)
> +{
> + return i2c_add_driver(_driver);
> +}
> +
> +static void exit_ov5648(void)
> +{
> +
> + i2c_del_driver(_driver);
> +}
> +
> +module_init(init_ov5648);
> +module_exit(exit_ov5648);
module_i2c_driver();
> +#ifndef __OV5648_H__
> +#define __OV5648_H__
+ empty line.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "../include/linux/atomisp_platform.h"
Why? Are they all needed for definitions below?
I'm pretty sure you may leave only couple out of them.
> +
> +#define OV5648_NAME "ov5648"
Why it's here?
> +static const struct i2c_device_id ov5648_id[] = {
> + {OV5648_NAME, 0},
> + {}
> +};
WTF?! It shouldn't be in the header!
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
Re: [PATCH] [media] staging: atomisp: use clock framework for camera clocks
On Wed, 2017-09-20 at 12:01 -0500, Pierre-Louis Bossart wrote:
>
> On 09/20/2017 04:12 AM, Andy Shevchenko wrote:
> > On Tue, 2017-09-19 at 15:45 -0500, Pierre-Louis Bossart wrote:
> > > The Atom ISP driver initializes and configures PMC clocks which
> > > are
> > > already handled by the clock framework.
> > >
> > > Remove all legacy vlv2_platform_clock stuff and move to the clk
> > > API to
> > > avoid conflicts, e.g. with audio machine drivers enabling the MCLK
> > > for
> > > external codecs
> > >
> >
> > I think it might have a Fixes: tag as well (though I dunno which
> > commit
> > could be considered as anchor).
>
> The initial integration of the atomisp driver already had this
> problem,
> i'll add a reference to
> 'a49d25364dfb9 ("staging/atomisp: Add support for the Intel IPU v2")'
...which seems to be the best choice (you can check how many new commits
use that one as an origin for Fixes: tag).
> >
> > (I doubt Git is so clever to remove files based on information out
> > of
> > the diff, can you check it and if needed to resend without -D
> > implied?)
>
> Gee, I thought -C -M -D were the standard options to checkpatch,
> never
> realized it'd prevent patches from applying. Thanks for the tip.
-C -M — yes for sure.
Last time I checked patches, generated with help of -D, do not remove
the files when you do git am. So, I don't know if it still the case.
Safe option is to use -C -M for public (+ -D locally only to see less
noise).
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
Re: [PATCH] [media] staging: atomisp: use clock framework for camera clocks
On Tue, 2017-09-19 at 15:45 -0500, Pierre-Louis Bossart wrote:
> The Atom ISP driver initializes and configures PMC clocks which are
> already handled by the clock framework.
>
> Remove all legacy vlv2_platform_clock stuff and move to the clk API to
> avoid conflicts, e.g. with audio machine drivers enabling the MCLK for
> external codecs
>
I think it might have a Fixes: tag as well (though I dunno which commit
could be considered as anchor).
(I doubt Git is so clever to remove files based on information out of
the diff, can you check it and if needed to resend without -D implied?)
Other than that - nice clean up!
Reviewed-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> Tested-by: Carlo Caione <ca...@endlessm.com>
> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.
> com>
> ---
> drivers/staging/media/atomisp/Kconfig | 1 +
> drivers/staging/media/atomisp/platform/Makefile| 1 -
> .../staging/media/atomisp/platform/clock/Makefile | 6 -
> .../platform/clock/platform_vlv2_plat_clk.c| 40
> .../platform/clock/platform_vlv2_plat_clk.h| 27 ---
> .../media/atomisp/platform/clock/vlv2_plat_clock.c | 247
> -
> .../platform/intel-mid/atomisp_gmin_platform.c | 63 +-
> 7 files changed, 52 insertions(+), 333 deletions(-)
> delete mode 100644
> drivers/staging/media/atomisp/platform/clock/Makefile
> delete mode 100644
> drivers/staging/media/atomisp/platform/clock/platform_vlv2_plat_clk.c
> delete mode 100644
> drivers/staging/media/atomisp/platform/clock/platform_vlv2_plat_clk.h
> delete mode 100644
> drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c
>
> diff --git a/drivers/staging/media/atomisp/Kconfig
> b/drivers/staging/media/atomisp/Kconfig
> index 8eb13c3ba29c..7cdebea35ccf 100644
> --- a/drivers/staging/media/atomisp/Kconfig
> +++ b/drivers/staging/media/atomisp/Kconfig
> @@ -1,6 +1,7 @@
> menuconfig INTEL_ATOMISP
> bool "Enable support to Intel MIPI camera drivers"
> depends on X86 && EFI && MEDIA_CONTROLLER && PCI && ACPI
> + select COMMON_CLK
> help
>Enable support for the Intel ISP2 camera interfaces and
> MIPI
>sensor drivers.
> diff --git a/drivers/staging/media/atomisp/platform/Makefile
> b/drivers/staging/media/atomisp/platform/Makefile
> index df157630bda9..0e3b7e1c81c6 100644
> --- a/drivers/staging/media/atomisp/platform/Makefile
> +++ b/drivers/staging/media/atomisp/platform/Makefile
> @@ -2,5 +2,4 @@
> # Makefile for camera drivers.
> #
>
> -obj-$(CONFIG_INTEL_ATOMISP) += clock/
> obj-$(CONFIG_INTEL_ATOMISP) += intel-mid/
> diff --git a/drivers/staging/media/atomisp/platform/clock/Makefile
> b/drivers/staging/media/atomisp/platform/clock/Makefile
> deleted file mode 100644
> index 82fbe8b6968a..
> diff --git
> a/drivers/staging/media/atomisp/platform/clock/platform_vlv2_plat_clk.
> c
> b/drivers/staging/media/atomisp/platform/clock/platform_vlv2_plat_clk.
> c
> deleted file mode 100644
> index 0aae9b0283bb..
> diff --git
> a/drivers/staging/media/atomisp/platform/clock/platform_vlv2_plat_clk.
> h
> b/drivers/staging/media/atomisp/platform/clock/platform_vlv2_plat_clk.
> h
> deleted file mode 100644
> index b730ab0e8223..
> diff --git
> a/drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c
> b/drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c
> deleted file mode 100644
> index f96789a31819..
> diff --git a/drivers/staging/media/atomisp/platform/intel-
> mid/atomisp_gmin_platform.c
> b/drivers/staging/media/atomisp/platform/intel-
> mid/atomisp_gmin_platform.c
> index edaae93af8f9..17b4cfae5abf 100644
> --- a/drivers/staging/media/atomisp/platform/intel-
> mid/atomisp_gmin_platform.c
> +++ b/drivers/staging/media/atomisp/platform/intel-
> mid/atomisp_gmin_platform.c
> @@ -4,10 +4,10 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> -#include "../../include/linux/vlv2_plat_clock.h"
> #include
> #include
> #include
> @@ -17,11 +17,7 @@
>
> #define MAX_SUBDEVS 8
>
> -/* Should be defined in vlv2_plat_clock API, isn't: */
> -#define VLV2_CLK_PLL_19P2MHZ 1
> -#define VLV2_CLK_XTAL_19P2MHZ 0
> -#define VLV2_CLK_ON 1
> -#define VLV2_CLK_OFF 2
> +#define VLV2_CLK_PLL_19P2MHZ 1 /* XTAL on CHT */
> #define ELDO1_SEL_REG0x19
> #define ELDO1_1P8V 0x16
> #define ELDO1_CTRL_SHIFT 0x00
> @@ -33,6 +29,7 @@ struct gmin_subdev {
> struct v4l2_subdev *subdev;
Re: [PATCH] staging: atomisp: add a driver for ov5648 camera sensor
On Mon, 2017-09-11 at 20:03 +0200, Devid Antonio Filoni wrote: > On Mon, Sep 11, 2017 at 05:55:29PM +0300, Sakari Ailus wrote: > > Hi Devid, > > > > Please see my comments below. > > > > Andy: please look for "INT5648". > > Hi Sakari, > I'm replying below to your comments. I'll work on a v2 patch as soon > as we get > more comments. > > About "INT5648", I extracted it from the DSDT of my Lenovo Miix 310, > take a look > at https://pastebin.com/ExHWYr8g . First of all, thank you, Sakari, to raise a flag here. Second, Devid, please answer to the following: is it an official BIOS which is available in the wild? If it's so, please, add a paragraph to the commit message explaining how do you get this and point to the DSDT excerpt. Put an answer to above question to the commit message as well. -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy
[PATCH v1 5/7] staging: atomisp: Move to upstream IOSF MBI API
There is a common for x86 IOSF MBI API. Move atomisp code to use it.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/staging/media/atomisp/pci/Kconfig | 1 +
.../media/atomisp/pci/atomisp2/atomisp_cmd.c | 20 +++-
.../media/atomisp/pci/atomisp2/atomisp_v4l2.c | 38 ++
3 files changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/Kconfig
b/drivers/staging/media/atomisp/pci/Kconfig
index a72421431c7a..fb66fc9d6952 100644
--- a/drivers/staging/media/atomisp/pci/Kconfig
+++ b/drivers/staging/media/atomisp/pci/Kconfig
@@ -5,6 +5,7 @@
config VIDEO_ATOMISP
tristate "Intel Atom Image Signal Processor Driver"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ select IOSF_MBI
select VIDEOBUF_VMALLOC
---help---
Say Y here if your platform supports Intel Atom SoC
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index f48bf451c1f5..73e15dd9d4d6 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -27,7 +27,9 @@
#include
#include
#include
+
#include
+#include
#include
#include
@@ -143,36 +145,36 @@ static int write_target_freq_to_hw(struct atomisp_device
*isp,
unsigned int ratio, timeout, guar_ratio;
u32 isp_sspm1 = 0;
int i;
+
if (!isp->hpll_freq) {
dev_err(isp->dev, "failed to get hpll_freq. no change to
freq\n");
return -EINVAL;
}
- isp_sspm1 = intel_mid_msgbus_read32(PUNIT_PORT, ISPSSPM1);
+ iosf_mbi_read(BT_MBI_UNIT_PMC, MBI_REG_READ, ISPSSPM1, _sspm1);
if (isp_sspm1 & ISP_FREQ_VALID_MASK) {
dev_dbg(isp->dev, "clearing ISPSSPM1 valid bit.\n");
- intel_mid_msgbus_write32(PUNIT_PORT, ISPSSPM1,
+ iosf_mbi_write(BT_MBI_UNIT_PMC, MBI_REG_WRITE, ISPSSPM1,
isp_sspm1 & ~(1 << ISP_FREQ_VALID_OFFSET));
}
ratio = (2 * isp->hpll_freq + new_freq / 2) / new_freq - 1;
guar_ratio = (2 * isp->hpll_freq + 200 / 2) / 200 - 1;
- isp_sspm1 = intel_mid_msgbus_read32(PUNIT_PORT, ISPSSPM1);
+ iosf_mbi_read(BT_MBI_UNIT_PMC, MBI_REG_READ, ISPSSPM1, _sspm1);
isp_sspm1 &= ~(0x1F << ISP_REQ_FREQ_OFFSET);
for (i = 0; i < ISP_DFS_TRY_TIMES; i++) {
- intel_mid_msgbus_write32(PUNIT_PORT, ISPSSPM1,
+ iosf_mbi_write(BT_MBI_UNIT_PMC, MBI_REG_WRITE, ISPSSPM1,
isp_sspm1
| ratio << ISP_REQ_FREQ_OFFSET
| 1 << ISP_FREQ_VALID_OFFSET
| guar_ratio << ISP_REQ_GUAR_FREQ_OFFSET);
- isp_sspm1 = intel_mid_msgbus_read32(PUNIT_PORT, ISPSSPM1);
-
+ iosf_mbi_read(BT_MBI_UNIT_PMC, MBI_REG_READ, ISPSSPM1,
_sspm1);
timeout = 20;
while ((isp_sspm1 & ISP_FREQ_VALID_MASK) && timeout) {
- isp_sspm1 = intel_mid_msgbus_read32(PUNIT_PORT,
ISPSSPM1);
+ iosf_mbi_read(BT_MBI_UNIT_PMC, MBI_REG_READ, ISPSSPM1,
_sspm1);
dev_dbg(isp->dev, "waiting for ISPSSPM1 valid bit to be
0.\n");
udelay(100);
timeout--;
@@ -187,10 +189,10 @@ static int write_target_freq_to_hw(struct atomisp_device
*isp,
return -EINVAL;
}
- isp_sspm1 = intel_mid_msgbus_read32(PUNIT_PORT, ISPSSPM1);
+ iosf_mbi_read(BT_MBI_UNIT_PMC, MBI_REG_READ, ISPSSPM1, _sspm1);
timeout = 10;
while (((isp_sspm1 >> ISP_FREQ_STAT_OFFSET) != ratio) && timeout) {
- isp_sspm1 = intel_mid_msgbus_read32(PUNIT_PORT, ISPSSPM1);
+ iosf_mbi_read(BT_MBI_UNIT_PMC, MBI_REG_READ, ISPSSPM1,
_sspm1);
dev_dbg(isp->dev, "waiting for ISPSSPM1 status bit to be
0x%x.\n",
new_freq);
udelay(100);
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index 663aa916e3ca..0896f5ea7e4e 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -28,6 +28,9 @@
#include
#include
+#include
+#include
+
#include "../../include/linux/atomisp_gmin_platform.h"
#include "atomisp_cmd.h"
@@ -46,7 +49,6 @@
#include "hrt/hive_isp_css_mm_hrt.h"
#include "device_access.h"
-#include
/* G-Min addition: pull this in from intel_mid_pm.h */
[PATCH v1 3/7] staging: atomisp: Remove dead code for MID (#2)
intel_mid_soc_stepping() is not used anywhere.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h | 1 -
.../media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c| 7 ---
2 files changed, 8 deletions(-)
diff --git a/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
b/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
index 0d7f5c618b56..5d8451ee391e 100644
--- a/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
+++ b/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
@@ -24,4 +24,3 @@ void intel_mid_msgbus_write32_raw(u32 cmd, u32 data);
void intel_mid_msgbus_write32(u8 port, u32 addr, u32 data);
u32 intel_mid_msgbus_read32_raw_ext(u32 cmd, u32 cmd_ext);
void intel_mid_msgbus_write32_raw_ext(u32 cmd, u32 cmd_ext, u32 data);
-u32 intel_mid_soc_stepping(void);
diff --git
a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
index 341bfd3ab313..c34f461653db 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
@@ -154,10 +154,3 @@ void intel_mid_msgbus_write32(u8 port, u32 addr, u32 data)
spin_unlock_irqrestore(_lock, irq_flags);
}
EXPORT_SYMBOL(intel_mid_msgbus_write32);
-
-/* called only from where is later then fs_initcall */
-u32 intel_mid_soc_stepping(void)
-{
- return pci_root->revision;
-}
-EXPORT_SYMBOL(intel_mid_soc_stepping);
--
2.14.1
[PATCH v1 7/7] staging: atomisp: Remove unneeded intel-mid.h inclusion
In many files in the driver the intel-mid.h header inclusion is redundant. Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> --- drivers/staging/media/atomisp/i2c/imx/drv201.c| 1 - drivers/staging/media/atomisp/i2c/imx/dw9714.c| 1 - drivers/staging/media/atomisp/i2c/imx/imx.c | 1 - drivers/staging/media/atomisp/i2c/imx/otp_imx.c | 1 - drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 1 - drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h | 2 -- drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c| 1 - drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c | 1 - drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 1 - drivers/staging/media/atomisp/platform/clock/platform_vlv2_plat_clk.h | 1 - 10 files changed, 11 deletions(-) diff --git a/drivers/staging/media/atomisp/i2c/imx/drv201.c b/drivers/staging/media/atomisp/i2c/imx/drv201.c index 6d9d4c968722..532af7da3158 100644 --- a/drivers/staging/media/atomisp/i2c/imx/drv201.c +++ b/drivers/staging/media/atomisp/i2c/imx/drv201.c @@ -16,7 +16,6 @@ #include #include #include -#include #include "drv201.h" diff --git a/drivers/staging/media/atomisp/i2c/imx/dw9714.c b/drivers/staging/media/atomisp/i2c/imx/dw9714.c index 6397a7ee0af6..7e58fb3589cc 100644 --- a/drivers/staging/media/atomisp/i2c/imx/dw9714.c +++ b/drivers/staging/media/atomisp/i2c/imx/dw9714.c @@ -16,7 +16,6 @@ #include #include #include -#include #include "dw9714.h" diff --git a/drivers/staging/media/atomisp/i2c/imx/imx.c b/drivers/staging/media/atomisp/i2c/imx/imx.c index 49ab0af87096..71b688970822 100644 --- a/drivers/staging/media/atomisp/i2c/imx/imx.c +++ b/drivers/staging/media/atomisp/i2c/imx/imx.c @@ -18,7 +18,6 @@ * 02110-1301, USA. * */ -#include #include "../../include/linux/atomisp_platform.h" #include #include diff --git a/drivers/staging/media/atomisp/i2c/imx/otp_imx.c b/drivers/staging/media/atomisp/i2c/imx/otp_imx.c index 1ca27c26ef75..279784cab6c3 100644 --- a/drivers/staging/media/atomisp/i2c/imx/otp_imx.c +++ b/drivers/staging/media/atomisp/i2c/imx/otp_imx.c @@ -30,7 +30,6 @@ #include #include #include -#include #include "common.h" /* Defines for OTP Data Registers */ diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c index 73e15dd9d4d6..b0c647f4d250 100644 --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c @@ -28,7 +28,6 @@ #include #include -#include #include #include diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h index 1fe1711387a2..6c1eb417361d 100644 --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h @@ -29,8 +29,6 @@ #include #include -#include - #include #include diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c index 717647951fb6..dd59167237c1 100644 --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c @@ -24,7 +24,6 @@ #include #include -#include #include #include diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c index 744ab6eb42a0..d27a50e66be2 100644 --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c @@ -25,7 +25,6 @@ #include #include #include -#include #include #include diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c index 0896f5ea7e4e..e85b3819bffa 100644 --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c @@ -28,7 +28,6 @@ #include #include -#include #include #include "../../include/linux/atomisp_gmin_platform.h" diff --git a/drivers/staging/media/atomisp/platform/clock/platform_vlv2_plat_clk.h b/drivers/staging/media/atomisp/platform/clock/platform_vlv2_plat_clk.h index b730ab0e8223..3bc0de129780 100644 --- a/drivers/staging/media/atomisp/platform/clock/platform_vlv2_plat_clk.h +++ b/drivers/staging/media/atomisp/platform/clock/platform_vlv2_plat_clk.h @@ -20,7 +20,6 @@ #define _PLATFORM_VLV2_PLAT_CLK_H_ #include -#include extern void __init *vlv2_plat_clk_device_platform_data( void *info) __attribute__((weak)); -- 2.14.1
[PATCH v1 6/7] staging: atomisp: Remove dead code for MID (#4)
Since we switched to upstream IOSF MBI API the custom code become not in
use anymore.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
.../atomisp/include/asm/intel_mid_pcihelpers.h | 22 -
.../media/atomisp/pci/atomisp2/atomisp_internal.h | 1 -
.../media/atomisp/platform/intel-mid/Makefile | 1 -
.../platform/intel-mid/intel_mid_pcihelpers.c | 98 --
4 files changed, 122 deletions(-)
delete mode 100644
drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
delete mode 100644
drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
diff --git a/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
b/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
deleted file mode 100644
index bf39f42c1c96..
--- a/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/*
- * Access to message bus through three registers
- * in CUNIT(0:0:0) PCI configuration space.
- * MSGBUS_CTRL_REG(0xD0):
- * 31:24 = message bus opcode
- * 23:16 = message bus port
- * 15:8 = message bus address, low 8 bits.
- * 7:4= message bus byte enables
- * MSGBUS_CTRL_EXT_REG(0xD8):
- * 31:8 = message bus address, high 24 bits.
- * MSGBUS_DATA_REG(0xD4):
- * hold the data for write or read
- */
-#define PCI_ROOT_MSGBUS_CTRL_REG0xD0
-#define PCI_ROOT_MSGBUS_DATA_REG0xD4
-#define PCI_ROOT_MSGBUS_CTRL_EXT_REG0xD8
-#define PCI_ROOT_MSGBUS_READ0x10
-#define PCI_ROOT_MSGBUS_WRITE 0x11
-#define PCI_ROOT_MSGBUS_DWORD_ENABLE0xf0
-
-u32 intel_mid_msgbus_read32(u8 port, u32 addr);
-void intel_mid_msgbus_write32(u8 port, u32 addr, u32 data);
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
index 7542a72f1d0f..1fe1711387a2 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
@@ -30,7 +30,6 @@
#include
#include
-#include "../../include/asm/intel_mid_pcihelpers.h"
#include
#include
diff --git a/drivers/staging/media/atomisp/platform/intel-mid/Makefile
b/drivers/staging/media/atomisp/platform/intel-mid/Makefile
index 4621261c35db..c53db1364e21 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/Makefile
+++ b/drivers/staging/media/atomisp/platform/intel-mid/Makefile
@@ -1,5 +1,4 @@
#
# Makefile for intel-mid devices.
#
-obj-$(CONFIG_INTEL_ATOMISP) += intel_mid_pcihelpers.o
obj-$(CONFIG_INTEL_ATOMISP) += atomisp_gmin_platform.o
diff --git
a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
deleted file mode 100644
index 4ed3268c4e63..
--- a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
+++ /dev/null
@@ -1,98 +0,0 @@
-#include
-#include
-#include
-#include
-
-/* G-Min addition: "platform_is()" lives in intel_mid_pm.h in the MCG
- * tree, but it's just platform ID info and we don't want to pull in
- * the whole SFI-based PM architecture.
- */
-#define INTEL_ATOM_MRST 0x26
-#define INTEL_ATOM_MFLD 0x27
-#define INTEL_ATOM_CLV 0x35
-#define INTEL_ATOM_MRFLD 0x4a
-#define INTEL_ATOM_BYT 0x37
-#define INTEL_ATOM_MOORFLD 0x5a
-#define INTEL_ATOM_CHT 0x4c
-static inline int platform_is(u8 model)
-{
- return (boot_cpu_data.x86_model == model);
-}
-
-#include "../../include/asm/intel_mid_pcihelpers.h"
-
-/* Unified message bus read/write operation */
-static DEFINE_SPINLOCK(msgbus_lock);
-
-static struct pci_dev *pci_root;
-static struct pm_qos_request pm_qos;
-
-#define DW_I2C_NEED_QOS(platform_is(INTEL_ATOM_BYT))
-
-static int intel_mid_msgbus_init(void)
-{
- pci_root = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
- if (!pci_root) {
- pr_err("%s: Error: msgbus PCI handle NULL\n", __func__);
- return -ENODEV;
- }
-
- if (DW_I2C_NEED_QOS) {
- pm_qos_add_request(_qos,
- PM_QOS_CPU_DMA_LATENCY,
- PM_QOS_DEFAULT_VALUE);
- }
- return 0;
-}
-fs_initcall(intel_mid_msgbus_init);
-
-u32 intel_mid_msgbus_read32(u8 port, u32 addr)
-{
- unsigned long irq_flags;
- u32 data;
- u32 cmd;
- u32 cmdext;
-
- cmd = (PCI_ROOT_MSGBUS_READ << 24) | (port << 16) |
- ((addr & 0xff) << 8) | PCI_ROOT_MSGBUS_DWORD_ENABLE;
- cmdext = addr & 0xff00;
-
- spin_lock_irqsave(_lock, irq_flags);
-
- if (cmdext) {
- /* This resets to 0 automatically, no need to write 0 */
- pci_write_config_dword(pci_root, PCI_ROOT_MSGBUS_CTRL_EXT_REG,
- cmdext);
- }
[PATCH v1 1/7] staging: atomisp: Remove dead code for MID (#1)
Remove dead code. If someone needs it the P-Unit semaphore is handled by
I2C DesignWare driver (drivers/i2c/busses/i2c-designware-baytrail.c).
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
.../atomisp/include/asm/intel_mid_pcihelpers.h | 2 -
.../platform/intel-mid/intel_mid_pcihelpers.c | 101 -
2 files changed, 103 deletions(-)
diff --git a/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
b/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
index c5e22bba455a..b7c079f3630a 100644
--- a/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
+++ b/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
@@ -33,5 +33,3 @@ void intel_mid_msgbus_write32(u8 port, u32 addr, u32 data);
u32 intel_mid_msgbus_read32_raw_ext(u32 cmd, u32 cmd_ext);
void intel_mid_msgbus_write32_raw_ext(u32 cmd, u32 cmd_ext, u32 data);
u32 intel_mid_soc_stepping(void);
-int intel_mid_dw_i2c_acquire_ownership(void);
-int intel_mid_dw_i2c_release_ownership(void);
diff --git
a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
index cd452cc20fea..0d01a269989d 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
@@ -14,13 +14,6 @@
#define INTEL_ATOM_BYT 0x37
#define INTEL_ATOM_MOORFLD 0x5a
#define INTEL_ATOM_CHT 0x4c
-/* synchronization for sharing the I2C controller */
-#define PUNIT_PORT 0x04
-#define PUNIT_DOORBELL_OPCODE (0xE0)
-#define PUNIT_DOORBELL_REG (0x0)
-#ifndef CSTATE_EXIT_LATENCY
-#define CSTATE_EXIT_LATENCY_C1 1
-#endif
static inline int platform_is(u8 model)
{
return (boot_cpu_data.x86_model == model);
@@ -201,97 +194,3 @@ static void pci_d3_delay_fixup(struct pci_dev *dev)
}
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_d3_delay_fixup);
-
-#define PUNIT_SEMAPHORE(platform_is(INTEL_ATOM_BYT) ? 0x7 : 0x10E)
-#define GET_SEM() (intel_mid_msgbus_read32(PUNIT_PORT, PUNIT_SEMAPHORE) & 0x1)
-
-static void reset_semaphore(void)
-{
- u32 data;
-
- data = intel_mid_msgbus_read32(PUNIT_PORT, PUNIT_SEMAPHORE);
- smp_mb();
- data = data & 0xfffc;
- intel_mid_msgbus_write32(PUNIT_PORT, PUNIT_SEMAPHORE, data);
- smp_mb();
-
-}
-
-int intel_mid_dw_i2c_acquire_ownership(void)
-{
- u32 ret = 0;
- u32 data = 0; /* data sent to PUNIT */
- u32 cmd;
- u32 cmdext;
- int timeout = 1000;
-
- if (DW_I2C_NEED_QOS)
- pm_qos_update_request(_qos, CSTATE_EXIT_LATENCY_C1 - 1);
-
- /*
-* We need disable irq. Otherwise, the main thread
-* might be preempted and the other thread jumps to
-* disable irq for a long time. Another case is
-* some irq handlers might trigger power voltage change
-*/
- BUG_ON(irqs_disabled());
- local_irq_disable();
-
- /* host driver writes 0x2 to side band register 0x7 */
- intel_mid_msgbus_write32(PUNIT_PORT, PUNIT_SEMAPHORE, 0x2);
- smp_mb();
-
- /* host driver sends 0xE0 opcode to PUNIT and writes 0 register */
- cmd = (PUNIT_DOORBELL_OPCODE << 24) | (PUNIT_PORT << 16) |
- ((PUNIT_DOORBELL_REG & 0xFF) << 8) | PCI_ROOT_MSGBUS_DWORD_ENABLE;
- cmdext = PUNIT_DOORBELL_REG & 0xff00;
-
- if (cmdext)
- intel_mid_msgbus_write32_raw_ext(cmd, cmdext, data);
- else
- intel_mid_msgbus_write32_raw(cmd, data);
-
- /* host driver waits for bit 0 to be set in side band 0x7 */
- while (GET_SEM() != 0x1) {
- udelay(100);
- timeout--;
- if (timeout <= 0) {
- pr_err("Timeout: semaphore timed out, reset sem\n");
- ret = -ETIMEDOUT;
- reset_semaphore();
- /*Delay 1ms in case race with punit*/
- udelay(1000);
- if (GET_SEM() != 0) {
- /*Reset again as kernel might race with punit*/
- reset_semaphore();
- }
- pr_err("PUNIT SEM: %d\n",
- intel_mid_msgbus_read32(PUNIT_PORT,
- PUNIT_SEMAPHORE));
- local_irq_enable();
-
- if (DW_I2C_NEED_QOS) {
- pm_qos_update_request(_qos,
-PM_QOS_DEFAULT_VALUE);
- }
-
- return ret;
- }
- }
- smp_mb();
-
- return ret;
-}
-EXPORT_SYMBOL(intel_mid_dw_i2c_acquire_ownership);
-
-int inte
[PATCH v1 4/7] staging: atomisp: Remove dead code for MID (#3)
intel_mid_msgbus_*_raw*() are not used anywhere.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
.../atomisp/include/asm/intel_mid_pcihelpers.h | 4 --
.../platform/intel-mid/intel_mid_pcihelpers.c | 58 --
2 files changed, 62 deletions(-)
diff --git a/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
b/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
index 5d8451ee391e..bf39f42c1c96 100644
--- a/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
+++ b/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
@@ -18,9 +18,5 @@
#define PCI_ROOT_MSGBUS_WRITE 0x11
#define PCI_ROOT_MSGBUS_DWORD_ENABLE0xf0
-u32 intel_mid_msgbus_read32_raw(u32 cmd);
u32 intel_mid_msgbus_read32(u8 port, u32 addr);
-void intel_mid_msgbus_write32_raw(u32 cmd, u32 data);
void intel_mid_msgbus_write32(u8 port, u32 addr, u32 data);
-u32 intel_mid_msgbus_read32_raw_ext(u32 cmd, u32 cmd_ext);
-void intel_mid_msgbus_write32_raw_ext(u32 cmd, u32 cmd_ext, u32 data);
diff --git
a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
index c34f461653db..4ed3268c4e63 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
@@ -46,64 +46,6 @@ static int intel_mid_msgbus_init(void)
}
fs_initcall(intel_mid_msgbus_init);
-u32 intel_mid_msgbus_read32_raw(u32 cmd)
-{
- unsigned long irq_flags;
- u32 data;
-
- spin_lock_irqsave(_lock, irq_flags);
- pci_write_config_dword(pci_root, PCI_ROOT_MSGBUS_CTRL_REG, cmd);
- pci_read_config_dword(pci_root, PCI_ROOT_MSGBUS_DATA_REG, );
- spin_unlock_irqrestore(_lock, irq_flags);
-
- return data;
-}
-EXPORT_SYMBOL(intel_mid_msgbus_read32_raw);
-
-/*
- * GU: this function is only used by the VISA and 'VXD' drivers.
- */
-u32 intel_mid_msgbus_read32_raw_ext(u32 cmd, u32 cmd_ext)
-{
- unsigned long irq_flags;
- u32 data;
-
- spin_lock_irqsave(_lock, irq_flags);
- pci_write_config_dword(pci_root, PCI_ROOT_MSGBUS_CTRL_EXT_REG, cmd_ext);
- pci_write_config_dword(pci_root, PCI_ROOT_MSGBUS_CTRL_REG, cmd);
- pci_read_config_dword(pci_root, PCI_ROOT_MSGBUS_DATA_REG, );
- spin_unlock_irqrestore(_lock, irq_flags);
-
- return data;
-}
-EXPORT_SYMBOL(intel_mid_msgbus_read32_raw_ext);
-
-void intel_mid_msgbus_write32_raw(u32 cmd, u32 data)
-{
- unsigned long irq_flags;
-
- spin_lock_irqsave(_lock, irq_flags);
- pci_write_config_dword(pci_root, PCI_ROOT_MSGBUS_DATA_REG, data);
- pci_write_config_dword(pci_root, PCI_ROOT_MSGBUS_CTRL_REG, cmd);
- spin_unlock_irqrestore(_lock, irq_flags);
-}
-EXPORT_SYMBOL(intel_mid_msgbus_write32_raw);
-
-/*
- * GU: this function is only used by the VISA and 'VXD' drivers.
- */
-void intel_mid_msgbus_write32_raw_ext(u32 cmd, u32 cmd_ext, u32 data)
-{
- unsigned long irq_flags;
-
- spin_lock_irqsave(_lock, irq_flags);
- pci_write_config_dword(pci_root, PCI_ROOT_MSGBUS_DATA_REG, data);
- pci_write_config_dword(pci_root, PCI_ROOT_MSGBUS_CTRL_EXT_REG, cmd_ext);
- pci_write_config_dword(pci_root, PCI_ROOT_MSGBUS_CTRL_REG, cmd);
- spin_unlock_irqrestore(_lock, irq_flags);
-}
-EXPORT_SYMBOL(intel_mid_msgbus_write32_raw_ext);
-
u32 intel_mid_msgbus_read32(u8 port, u32 addr)
{
unsigned long irq_flags;
--
2.14.1
[PATCH v1 2/7] staging: atomisp: Don't override D3 delay settings here
The d3_delay parameter is set by arch/x86/pci/intel_mid_pci.c and
drivers/pci/quirks.c.
No need to override that settings in unrelated driver.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
.../atomisp/include/asm/intel_mid_pcihelpers.h | 8 --
.../platform/intel-mid/intel_mid_pcihelpers.c | 33 --
2 files changed, 41 deletions(-)
diff --git a/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
b/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
index b7c079f3630a..0d7f5c618b56 100644
--- a/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
+++ b/drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
@@ -18,14 +18,6 @@
#define PCI_ROOT_MSGBUS_WRITE 0x11
#define PCI_ROOT_MSGBUS_DWORD_ENABLE0xf0
-/* In BYT platform for all internal PCI devices d3 delay
- * of 3 ms is sufficient. Default value of 10 ms is overkill.
- */
-#define INTERNAL_PCI_PM_D3_WAIT3
-
-#define ISP_SUB_CLASS 0x80
-#define SUB_CLASS_MASK 0xFF00
-
u32 intel_mid_msgbus_read32_raw(u32 cmd);
u32 intel_mid_msgbus_read32(u8 port, u32 addr);
void intel_mid_msgbus_write32_raw(u32 cmd, u32 data);
diff --git
a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
index 0d01a269989d..341bfd3ab313 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
@@ -161,36 +161,3 @@ u32 intel_mid_soc_stepping(void)
return pci_root->revision;
}
EXPORT_SYMBOL(intel_mid_soc_stepping);
-
-static bool is_south_complex_device(struct pci_dev *dev)
-{
- unsigned int base_class = dev->class >> 16;
- unsigned int sub_class = (dev->class & SUB_CLASS_MASK) >> 8;
-
- /* other than camera, pci bridges and display,
-* everything else are south complex devices.
-*/
- if (((base_class == PCI_BASE_CLASS_MULTIMEDIA) &&
-(sub_class == ISP_SUB_CLASS)) ||
- (base_class == PCI_BASE_CLASS_BRIDGE) ||
- ((base_class == PCI_BASE_CLASS_DISPLAY) && !sub_class))
- return false;
- else
- return true;
-}
-
-/* In BYT platform, d3_delay for internal south complex devices,
- * they are not subject to 10 ms d3 to d0 delay required by pci spec.
- */
-static void pci_d3_delay_fixup(struct pci_dev *dev)
-{
- if (platform_is(INTEL_ATOM_BYT) ||
- platform_is(INTEL_ATOM_CHT)) {
- /* All internal devices are in bus 0. */
- if (dev->bus->number == 0 && is_south_complex_device(dev)) {
- dev->d3_delay = INTERNAL_PCI_PM_D3_WAIT;
- dev->d3cold_delay = INTERNAL_PCI_PM_D3_WAIT;
- }
- }
-}
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_d3_delay_fixup);
--
2.14.1
Re: [PATCH v2 09/12] intel-ipu3: css hardware setup
On Sat, Jun 17, 2017 at 9:43 PM, Sakari Ailus <sakari.ai...@iki.fi> wrote:
> On Sat, Jun 17, 2017 at 01:54:51AM +0300, Andy Shevchenko wrote:
>> On Thu, Jun 15, 2017 at 1:19 AM, Yong Zhi <yong@intel.com> wrote:
>> > +static void writes(void *mem, ssize_t len, void __iomem *reg)
>> > +{
>> > + while (len >= 4) {
>> > + writel(*(u32 *)mem, reg);
>> > + mem += 4;
>> > + reg += 4;
>> > + len -= 4;
>> > + }
>> > +}
>>
>> Again, I just looked into patches and first what I see is reinventing the
>> wheel.
>>
>> memcpy_toio()
> That doesn't quite work: the hardware only supports 32-bit access.
>
> So the answer is writesl().
Makes sense!
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 12/12] intel-ipu3: imgu top level pci device
On Sat, Jun 17, 2017 at 9:32 AM, Tomasz Figa <tf...@chromium.org> wrote:
> On Sat, Jun 17, 2017 at 9:00 AM, Zhi, Yong <yong@intel.com> wrote:
>>> On Thu, Jun 15, 2017 at 1:19 AM, Yong Zhi <yong@intel.com> wrote:
>>> > + /* Set Power */
>>> > + r = pm_runtime_get_sync(dev);
>>> > + if (r < 0) {
>>> > + dev_err(dev, "failed to set imgu power\n");
>>>
>>> > + pm_runtime_put(dev);
>>>
>>> I'm not sure it's a right thing to do.
>>> How did you test runtime PM counters in this case?
>>>
>>> > + return r;
>>> > + }
>> Actually I have not tested the error case, what the right way to do in your
>> opinion? there is no checking of this function return in lot of the driver
>> code, or simply returning the error code, I also saw examples to call either
>> pm_runtime_put() or pm_runtime_put_noidle() in this case.
>
> Instead of speculating, if we inspect pm_runtime_get_sync() [1], we
> can see that it always causes the runtime PM counter to increment, but
> it never decrements it, even in case of error. So to keep things
> balanced, you need to call pm_runtime_put() in error path.
>
> It shouldn't matter if it's pm_runtime_put() or
> pm_runtime_put_noidle(), because of runtime PM semantics, which are
> explicitly specified [2] that after an error, no hardware state change
> is attempted until the state is explicitly reset by the driver with
> either pm_runtime_set_active() or pm_runtime_set_suspended().
>
> So, as far as I didn't miss some even more obscure bits of the runtime
> PM framework, current code is fine.
Indeed. Thanks for explanation. PM runtime is hard :-)
Previously I didn't meet (and actually never used) check for returning
code of pm_runtime_get*().
> [1]
> http://elixir.free-electrons.com/linux/v4.11.6/source/include/linux/pm_runtime.h#L235
> and the main part:
> http://elixir.free-electrons.com/linux/v4.11.6/source/drivers/base/power/runtime.c#L1027
>
> [2]
> http://elixir.free-electrons.com/linux/v4.11.6/source/Documentation/power/runtime_pm.txt#L128
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 12/12] intel-ipu3: imgu top level pci device
On Thu, Jun 15, 2017 at 1:19 AM, Yong Zhi <yong@intel.com> wrote:
Commit message.
> Signed-off-by: Yong Zhi <yong@intel.com>
> + /* Set Power */
> + r = pm_runtime_get_sync(dev);
> + if (r < 0) {
> + dev_err(dev, "failed to set imgu power\n");
> + pm_runtime_put(dev);
I'm not sure it's a right thing to do.
How did you test runtime PM counters in this case?
> + return r;
> + }
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 09/12] intel-ipu3: css hardware setup
On Thu, Jun 15, 2017 at 1:19 AM, Yong Zhi <yong@intel.com> wrote:
Commit message.
> Signed-off-by: Yong Zhi <yong@intel.com>
> +static void writes(void *mem, ssize_t len, void __iomem *reg)
> +{
> + while (len >= 4) {
> + writel(*(u32 *)mem, reg);
> + mem += 4;
> + reg += 4;
> + len -= 4;
> + }
> +}
Again, I just looked into patches and first what I see is reinventing the wheel.
memcpy_toio()
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 08/12] intel-ipu3: params: compute and program ccs
On Thu, Jun 15, 2017 at 1:19 AM, Yong Zhi <yong@intel.com> wrote:
> A collection of routines that are mainly responsible
> to calculate the acc parameters.
> +static unsigned int ipu3_css_scaler_get_exp(unsigned int counter,
> + unsigned int divider)
> +{
> + unsigned int i = 0;
> +
> + while (counter <= divider / 2) {
> + divider /= 2;
> + i++;
> + }
> +
> + return i;
We have a lot of different helpers including one you may use instead
of this function.
It's *highly* recommended you learn what we have under lib/ (and not
only there) in kernel bewfore submitting a new version.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 00/12] Intel IPU3 ImgU patchset
On Thu, Jun 15, 2017 at 1:26 AM, Sakari Ailus <sakari.ai...@iki.fi> wrote: > On Mon, Jun 05, 2017 at 09:46:59PM +0100, Alan Cox wrote: >> and a pointer to the firmware (which ideally should go into the standard >> Linux firmware git) > > Good question. Let me see what I can find. Just a side note: it would be good to put it there. Hopefully the firmware for IPUv3 is not going to be changed two times per day. -- With Best Regards, Andy Shevchenko
[PATCH v1] [media] as3645a: Join string literals back
There is no need to split long string literals.
Join them back.
No functional change intended.
Signed-off-by: Andy Shevchenko <andy.shevche...@gmail.com>
---
drivers/media/i2c/as3645a.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/as3645a.c b/drivers/media/i2c/as3645a.c
index b6aeceea9850..af5db71a0888 100644
--- a/drivers/media/i2c/as3645a.c
+++ b/drivers/media/i2c/as3645a.c
@@ -294,8 +294,8 @@ static int as3645a_read_fault(struct as3645a *flash)
dev_dbg(>dev, "Inductor Peak limit fault\n");
if (rval & AS_FAULT_INFO_INDICATOR_LED)
- dev_dbg(>dev, "Indicator LED fault: "
- "Short circuit or open loop\n");
+ dev_dbg(>dev,
+ "Indicator LED fault: Short circuit or open loop\n");
dev_dbg(>dev, "%u connected LEDs\n",
rval & AS_FAULT_INFO_LED_AMOUNT ? 2 : 1);
@@ -310,8 +310,8 @@ static int as3645a_read_fault(struct as3645a *flash)
dev_dbg(>dev, "Short circuit fault\n");
if (rval & AS_FAULT_INFO_OVER_VOLTAGE)
- dev_dbg(>dev, "Over voltage fault: "
- "Indicates missing capacitor or open connection\n");
+ dev_dbg(>dev,
+ "Over voltage fault: Indicates missing capacitor or
open connection\n");
return rval;
}
@@ -583,8 +583,8 @@ static int as3645a_registered(struct v4l2_subdev *sd)
/* Verify the chip model and version. */
if (model != 0x01 || rfu != 0x00) {
- dev_err(>dev, "AS3645A not detected "
- "(model %d rfu %d)\n", model, rfu);
+ dev_err(>dev,
+ "AS3645A not detected (model %d rfu %d)\n", model, rfu);
rval = -ENODEV;
goto power_off;
}
--
2.13.0
Re: [PATCH 2/7] staging: atomisp: Do not call dev_warn with a NULL device
On Sun, May 28, 2017 at 3:31 PM, Hans de Goede <hdego...@redhat.com> wrote: > Do not call dev_warn with a NULL device, this silence the following 2 > warnings: > > [ 14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO > [ 14.392257] (NULL device *): Failed to find gmin variable gmin_V1P8GPIO > > We could switch to using pr_warn for dev == NULL instead, but as comments > in the source indicate, the check for these 2 special gmin variables with > a NULL device is a workaround for 2 specific evaluation boards, so > completely silencing the missing warning for these actually is a good > thing. Perhaps removing all code related explicitly to Gmin is a right thing to do. -- With Best Regards, Andy Shevchenko
Re: [PATCH v2 4/7] x86: put msr-index.h in uapi
On Fri, Jan 6, 2017 at 11:43 AM, Nicolas Dichtel <nicolas.dich...@6wind.com> wrote: > This header file is exported, thus move it to uapi. Just hint for the future: -M (move) -C (copy) -D (delete) [though this is NOT for applying] -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 1/1] tea575x: convert to library
The module is used only as a library for now. Remove module init and exit
routines to show this.
While here, remove FSF snail address and attach EXPORT_SYMBOL() macros to
corresponding functions.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/media/radio/tea575x.c | 21 ++---
1 file changed, 2 insertions(+), 19 deletions(-)
diff --git a/drivers/media/radio/tea575x.c b/drivers/media/radio/tea575x.c
index 43d1ea5..21cd5de 100644
--- a/drivers/media/radio/tea575x.c
+++ b/drivers/media/radio/tea575x.c
@@ -14,10 +14,6 @@
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- *
*/
#include
@@ -226,6 +222,7 @@ void snd_tea575x_set_freq(struct snd_tea575x *tea)
snd_tea575x_write(tea, tea->val);
tea->freq = snd_tea575x_val_to_freq(tea, tea->val);
}
+EXPORT_SYMBOL(snd_tea575x_set_freq);
/*
* Linux Video interface
@@ -582,25 +579,11 @@ int snd_tea575x_init(struct snd_tea575x *tea, struct
module *owner)
return 0;
}
+EXPORT_SYMBOL(snd_tea575x_init);
void snd_tea575x_exit(struct snd_tea575x *tea)
{
video_unregister_device(>vd);
v4l2_ctrl_handler_free(tea->vd.ctrl_handler);
}
-
-static int __init alsa_tea575x_module_init(void)
-{
- return 0;
-}
-
-static void __exit alsa_tea575x_module_exit(void)
-{
-}
-
-module_init(alsa_tea575x_module_init)
-module_exit(alsa_tea575x_module_exit)
-
-EXPORT_SYMBOL(snd_tea575x_init);
EXPORT_SYMBOL(snd_tea575x_exit);
-EXPORT_SYMBOL(snd_tea575x_set_freq);
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On Fri, Nov 20, 2015 at 12:58 PM, Arnd Bergmann <a...@arndb.de> wrote: > On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: >> On 11/19/2015 01:25 PM, Arnd Bergmann wrote: > Another idea would be to remove the filter function from struct dma_chan_map > and pass the map through platform data Why not unified device properties? -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On Fri, Nov 20, 2015 at 2:30 PM, Peter Ujfalusi <peter.ujfal...@ti.com> wrote: > On 11/20/2015 02:24 PM, Andy Shevchenko wrote: >> On Fri, Nov 20, 2015 at 12:58 PM, Arnd Bergmann <a...@arndb.de> wrote: >>> On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: >>>> On 11/19/2015 01:25 PM, Arnd Bergmann wrote: >> >>> Another idea would be to remove the filter function from struct dma_chan_map >>> and pass the map through platform data >> >> Why not unified device properties? > > Is this some Windows/ACPI feature? Nope. Check drivers/base/property.c > Quick search gives mostly MSDN and > Windows10 related links. > > We only need dma_chan_map for platforms which has not been converted to DT and > still using legacy boot. Or platforms which can still boot in legacy mode. In > DT/ACPI mode we do not need this map at all. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On Wed, Nov 18, 2015 at 5:51 PM, Arnd Bergmann <a...@arndb.de> wrote: > On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote: >> > >> > I assume that the sst-firmware.c case is a mistake, it should just use a >> > plain DMA_SLAVE and not DMA_MEMCPY. >> >> Other way around. >> > > Ok, I see. In that case I guess it also shouldn't call > dmaengine_slave_config(), right? I don't think that's valid > on a MEMCPY channel. Hmm… That's right, though I suspect still one thing why it's done this way. Let's ask Vinod and Liam about that. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On Wed, Nov 18, 2015 at 4:21 PM, Peter Ujfalusi <peter.ujfal...@ti.com> wrote: > Hi Vinod, > > bringing this old thread back to life as I just started to work on this. What I remember we need to convert drivers to use new API meanwhile it is good to keep old one to avoid patch storm which does nothing useful (IIRC Russel's opinion). On the other hand there are a lot of drivers that are used on the set of platforms starting from legacy and abandoned ones (like AVR32) to relatively new and newest. And I'm not a fan of those thousands of API calls either. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On Wed, Nov 18, 2015 at 5:07 PM, Arnd Bergmann <a...@arndb.de> wrote: > On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote: >> On 11/18/2015 04:29 PM, Arnd Bergmann wrote: >> > On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote: >> >> 2. non slave channel requests, where only the functionality matters, like >> >> memcpy, interleaved, memset, etc. >> >> We could have a simple: >> >> dma_request_channel(mask); >> >> >> >> But looking at the drivers using dmaengine legacy dma_request_channel() >> >> API: >> >> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE: >> >> drivers/misc/carma/carma-fpga.c >> >> DMA_INTERRUPT|DMA_SLAVE|DMA_SG >> >> drivers/misc/carma/carma-fpga-program.c >> >> DMA_MEMCPY|DMA_SLAVE|DMA_SG >> >> drivers/media/platform/soc_camera/mx3_camera.c DMA_SLAVE|DMA_PRIVATE >> >> sound/soc/intel/common/sst-firmware.c DMA_SLAVE|DMA_MEMCPY >> >> >> >> as examples. >> >> Not sure how valid are these... > > I just had a look myself. carma has been removed fortunately in linux-next, > so we don't have to worry about that any more. > > I assume that the sst-firmware.c case is a mistake, it should just use a > plain DMA_SLAVE and not DMA_MEMCPY. Other way around. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] initial clkdev cleanups
On Mon, 2015-03-02 at 13:50 -0800, Stephen Boyd wrote: On 03/02/15 09:05, Russell King - ARM Linux wrote: Here's some initial clkdev cleanups. These are targetted for the next merge window, and while the initial patches can be merged independently, I'd prefer to keep the series together as further work on solving the problems which unique struct clk's has introduced is needed. I'm also killing a chunk of seemingly unused code in the omap3isp driver. Lastly, I'm introducing a clkdev_create() helper, which combines the clkdev_alloc() + clkdev_add() pattern which keeps cropping up. We already have a solution to that problem with clk_register_clkdev(). Andy has done some work to make clk_register_clkdev() return a struct clk_lookup pointer[1]. Maybe we can do that instead of introducing a new clkdev_create() function. There is some benefit to having a new function though so that we can avoid a flag day, although it looks like the flag day is small in this case so it might not actually matter. [1] https://www.marc.info/?l=linux-kernelm=142469226512289 Agree with Stephen, why should we have the second function doing the same? Just name changing? I think you may just incorporate that patch into your series. -- Andy Shevchenko andriy.shevche...@intel.com Intel Finland Oy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:media_tree/master] [media] lirc_dev: avoid potential null-dereference
On Tue, Feb 3, 2015 at 9:33 PM, Mauro Carvalho Chehab
mche...@osg.samsung.com wrote:
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/cgit.cgi/media_tree.git tree:
Subject: [media] lirc_dev: avoid potential null-dereference
Author: Andy Shevchenko andy.shevche...@gmail.com
Date:Tue Jan 6 22:53:37 2015 -0300
We have to check pointer for NULL and then dereference it.
Sorry, seems I forgot to write that it is non-needed fix.
Regarding to the current poll_wait() implementation and that fact that
wait_poll is a first member of the struct lirc_buffer there is no
dereference.
Signed-off-by: Andy Shevchenko andy.shevche...@gmail.com
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
drivers/media/rc/lirc_dev.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
---
http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?id=3656cddd50018d562d2df87c4698783898732914
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 1e0545a..4de0e85 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -553,14 +553,14 @@ unsigned int lirc_dev_fop_poll(struct file *file,
poll_table *wait)
if (!ir-attached)
return POLLERR;
- poll_wait(file, ir-buf-wait_poll, wait);
+ if (ir-buf) {
+ poll_wait(file, ir-buf-wait_poll, wait);
- if (ir-buf)
if (lirc_buffer_empty(ir-buf))
ret = 0;
else
ret = POLLIN | POLLRDNORM;
- else
+ } else
ret = POLLERR;
dev_dbg(ir-d.dev, LOGHEAD poll result = %d\n,
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: i2c: add new driver for single string flash.
;
+
+ i2c_set_clientdata(client, flash);
+
+ return 0;
+}
+
+static int ssflash_remove(struct i2c_client *client)
+{
+ struct ssflash_flash *flash = i2c_get_clientdata(client);
+
+ v4l2_device_unregister_subdev(flash-subdev_led);
+ v4l2_ctrl_handler_free(flash-ctrls_led);
+ media_entity_cleanup(flash-subdev_led.entity);
+
+ return 0;
+}
+
+static const struct i2c_device_id ssflash_id_table[] = {
+ {LM3556_NAME, (unsigned long)flash_lm3556},
+ {LM3561_NAME, (unsigned long)flash_lm3561},
+ {LM3642_NAME, (unsigned long)flash_lm3642},
+ {LM3648_NAME, (unsigned long)flash_lm3648},
+ {}
+};
+
+MODULE_DEVICE_TABLE(i2c, ssflash_id_table);
+
+static struct i2c_driver ssflash_i2c_driver = {
+ .driver = {
+ .name = SINGLE_STRING_FLASH_NAME,
+ },
+ .probe = ssflash_probe,
+ .remove = ssflash_remove,
+ .id_table = ssflash_id_table,
+};
+
+module_i2c_driver(ssflash_i2c_driver);
+
+MODULE_AUTHOR(Daniel Jeong gshark.je...@gmail.com);
+MODULE_AUTHOR(Ldd Mlp ldd-...@list.ti.com);
+MODULE_DESCRIPTION(Texas Instruments single string LED flash driver);
+MODULE_LICENSE(GPL);
diff --git a/include/media/ti-ss-flash.h b/include/media/ti-ss-flash.h
new file mode 100644
index 000..505b33f
--- /dev/null
+++ b/include/media/ti-ss-flash.h
@@ -0,0 +1,33 @@
+/*
+ * include/media/ti-ss-flash.h
+ *
+ * Copyright (C) 2014 Texas Instruments
+ *
+ * Contact: Daniel Jeong gshark.je...@gmail.com
+ * Ldd-Mlp ldd-...@list.ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#ifndef __TI_SS_FLASH_H__
+#define __TI_SS_FLASH_H__
+
+#include media/v4l2-subdev.h
+
+#define LM3556_NAME lm3556
+#define LM3556_I2C_ADDR (0x63)
+
+#define LM3561_NAME lm3561
+#define LM3561_I2C_ADDR (0x53)
+
+#define LM3642_NAME lm3642
+#define LM3642_I2C_ADDR (0x63)
+
+#define LM3648_NAME lm3648
+#define LM3648_I2C_ADDR (0x63)
+
+#define SINGLE_STRING_FLASH_NAME ti_ss_flash
+
+#endif /* __TI_SS_FLASH_H__ */
--
Andy Shevchenko andriy.shevche...@intel.com
Intel Finland Oy
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] soc_camera: avoid potential null-dereference
On Wed, Jan 7, 2015 at 9:44 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Hi Andy,
Thanks for the patch. Will queue for the next pull request.
If you didn't do that please wait. It seems it has one more place with
similar issue. Moreover, I would like to add a person's name who
reported this.
Regards
Guennadi
On Wed, 7 Jan 2015, Andy Shevchenko wrote:
We have to check the pointer before dereferencing it.
Signed-off-by: Andy Shevchenko andy.shevche...@gmail.com
---
drivers/media/platform/soc_camera/soc_camera.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index b3db51c..8c665c4 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -2166,7 +2166,7 @@ static int soc_camera_video_start(struct
soc_camera_device *icd)
static int soc_camera_pdrv_probe(struct platform_device *pdev)
{
struct soc_camera_desc *sdesc = pdev-dev.platform_data;
- struct soc_camera_subdev_desc *ssdd = sdesc-subdev_desc;
+ struct soc_camera_subdev_desc *ssdd;
struct soc_camera_device *icd;
int ret;
@@ -2177,6 +2177,8 @@ static int soc_camera_pdrv_probe(struct
platform_device *pdev)
if (!icd)
return -ENOMEM;
+ ssdd = sdesc-subdev_desc;
+
/*
* In the asynchronous case ssdd-num_regulators == 0 yet, so, the
below
* regulator allocation is a dummy. They are actually requested by the
--
1.8.3.101.g727a46b
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] soc_camera: avoid potential null-dereference
On Wed, Jan 7, 2015 at 10:05 PM, Andy Shevchenko
andy.shevche...@gmail.com wrote:
On Wed, Jan 7, 2015 at 9:44 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Hi Andy,
Thanks for the patch. Will queue for the next pull request.
If you didn't do that please wait. It seems it has one more place with
similar issue. Moreover, I would like to add a person's name who
reported this.
Okay, the second one is false positive.
And
Reported-by: Andrey Karpov kar...@viva64.com
Regards
Guennadi
On Wed, 7 Jan 2015, Andy Shevchenko wrote:
We have to check the pointer before dereferencing it.
Signed-off-by: Andy Shevchenko andy.shevche...@gmail.com
---
drivers/media/platform/soc_camera/soc_camera.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index b3db51c..8c665c4 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -2166,7 +2166,7 @@ static int soc_camera_video_start(struct
soc_camera_device *icd)
static int soc_camera_pdrv_probe(struct platform_device *pdev)
{
struct soc_camera_desc *sdesc = pdev-dev.platform_data;
- struct soc_camera_subdev_desc *ssdd = sdesc-subdev_desc;
+ struct soc_camera_subdev_desc *ssdd;
struct soc_camera_device *icd;
int ret;
@@ -2177,6 +2177,8 @@ static int soc_camera_pdrv_probe(struct
platform_device *pdev)
if (!icd)
return -ENOMEM;
+ ssdd = sdesc-subdev_desc;
+
/*
* In the asynchronous case ssdd-num_regulators == 0 yet, so, the
below
* regulator allocation is a dummy. They are actually requested by the
--
1.8.3.101.g727a46b
--
With Best Regards,
Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] lirc_dev: avoid potential null-dereference
We have to check pointer for NULL and then dereference it.
Signed-off-by: Andy Shevchenko andy.shevche...@gmail.com
---
drivers/media/rc/lirc_dev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 1e0545a..4de0e85 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -553,14 +553,14 @@ unsigned int lirc_dev_fop_poll(struct file *file,
poll_table *wait)
if (!ir-attached)
return POLLERR;
- poll_wait(file, ir-buf-wait_poll, wait);
+ if (ir-buf) {
+ poll_wait(file, ir-buf-wait_poll, wait);
- if (ir-buf)
if (lirc_buffer_empty(ir-buf))
ret = 0;
else
ret = POLLIN | POLLRDNORM;
- else
+ } else
ret = POLLERR;
dev_dbg(ir-d.dev, LOGHEAD poll result = %d\n,
--
1.8.3.101.g727a46b
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] soc_camera: avoid potential null-dereference
We have to check the pointer before dereferencing it.
Signed-off-by: Andy Shevchenko andy.shevche...@gmail.com
---
drivers/media/platform/soc_camera/soc_camera.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index b3db51c..8c665c4 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -2166,7 +2166,7 @@ static int soc_camera_video_start(struct
soc_camera_device *icd)
static int soc_camera_pdrv_probe(struct platform_device *pdev)
{
struct soc_camera_desc *sdesc = pdev-dev.platform_data;
- struct soc_camera_subdev_desc *ssdd = sdesc-subdev_desc;
+ struct soc_camera_subdev_desc *ssdd;
struct soc_camera_device *icd;
int ret;
@@ -2177,6 +2177,8 @@ static int soc_camera_pdrv_probe(struct platform_device
*pdev)
if (!icd)
return -ENOMEM;
+ ssdd = sdesc-subdev_desc;
+
/*
* In the asynchronous case ssdd-num_regulators == 0 yet, so, the below
* regulator allocation is a dummy. They are actually requested by the
--
1.8.3.101.g727a46b
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
