| Message ID | 20200622171910.608894-1-jacopo@jmondi.org |
|---|---|
| Headers | show |
| Series |
|
| Related | show |
My ISP has rejected the rest of the series: too many emails :( Has it ever happened to anyone else ? How did you solved this ? I'll send the rest of the series tomorrow. Sorry about this. On Mon, Jun 22, 2020 at 07:18:45PM +0200, Jacopo Mondi wrote: > Hello, > this series improves and expand the existing ov5647 sensor driver to > the same feature level as found in RaspberryPi BSP. > > It is based on recent media tree master and the sensor bindings conversion > to dt-schema I sent out a few days ago: > "[PATCH 0/2] dt-bidings: media: ov5647 bindings + small fix" > > The first patches in the series has been sent by Roman as part of > "[PATCH v2 0/6] ov5647 driver improvement" > I took his patches in, addressed review comments and rebased on top > of the new dt-schema bindings. I kept the extensive receiver list he had > in his series for this reason. > > The series continues by polishing and cleaning up the driver and expanding > its functionalities to support multiple modes and image formats. > > The series has been tested with libcamera and the driver functionalities > compared with the BSP driver ones, and tested stand-alone by capturing > raw frames with yavta. > > Thanks > j > > Dave Stevenson (8): > media: ov5647: Add support for PWDN GPIO. > media: ov5647: Add support for non-continuous clock mode > media: ov5647: Add set_fmt and get_fmt calls. > media: ov5647: Add support for get_selection() > media: ov5647: Set V4L2_SUBDEV_FL_HAS_EVENTS flag > media: ov5647: Support V4L2_CID_PIXEL_RATE > media: ov5647: Support V4L2_CID_VBLANK control > media: ov5647: Advertise the correct exposure range > > David Plowman (1): > media: ov5647: Support gain, exposure and AWB controls > > Jacopo Mondi (16): > dt-bindings: media: ov5647: Document pwdn-gpios > dt-bindings: media: ov5647: Document clock-noncontinuous > media: ov5647: Fix format initialization > media: ov5647: Fix style issues > media: ov5647: Replace license with SPDX identifier > media: ov5647: Fix return value from read/write > media: ov5647: Program mode at s_stream(1) time > media: ov5647: Implement enum_frame_size() > media: ov5647: Protect s_stream() with mutex > media: ov5647: Rationalize driver structure name > media: ov5647: Break out format handling > media: ov5647: Rename SBGGR8 VGA mode > media: ov5647: Add SGGBR10_1X10 modes > media: ov5647: Implement set_fmt pad operation > media: ov5647: Program mode only if it has changed > media: ov5647: Support V4L2_CID_HBLANK control > > .../devicetree/bindings/media/i2c/ov5647.yaml | 11 + > drivers/media/i2c/ov5647.c | 1267 +++++++++++++++-- > 2 files changed, 1126 insertions(+), 152 deletions(-) > > -- > 2.27.0 >
Hi Jacopo, Many thanks for your precious contribution. On Mon, Jun 22, 2020 at 07:26:14PM +0200, Jacopo Mondi wrote: > My ISP has rejected the rest of the series: too many emails :( > Has it ever happened to anyone else ? How did you solved this ? I guess leaving 5-10 seconds between sending individual patches should overcome this? I wonder if git provides a built-in command for that?
Hi Eugeniu, On Tue, Jun 23, 2020 at 12:30:02PM +0200, Eugeniu Rosca wrote: > Hi Jacopo, > > Many thanks for your precious contribution. > > On Mon, Jun 22, 2020 at 07:26:14PM +0200, Jacopo Mondi wrote: > > My ISP has rejected the rest of the series: too many emails :( > > Has it ever happened to anyone else ? How did you solved this ? > > I guess leaving 5-10 seconds between sending individual patches should > overcome this? I wonder if git provides a built-in command for that? > git send-email does provide the --batch-size --relogin-delay options, as Ezequiel suggested me in #v4l. I tried re-sending with a 10 email batch and a 5 seconds delay but I got the same failure. I was not able to find any description of the email number limits for the SMTP server I'm using, so I could only go and try. I think the extensive CC list of this series which I got from Roman's series plays a role, so I can't try just by sending to myself... I wonder if I should send the series in chunks, the first 10 patches went out (2 times '-.- ) already... > -- > Best regards, > Eugeniu Rosca
Hi Jacopo, On Tue, Jun 23, 2020 at 12:49:03PM +0200, Jacopo Mondi wrote: > On Tue, Jun 23, 2020 at 12:30:02PM +0200, Eugeniu Rosca wrote: > > On Mon, Jun 22, 2020 at 07:26:14PM +0200, Jacopo Mondi wrote: > > > My ISP has rejected the rest of the series: too many emails :( > > > Has it ever happened to anyone else ? How did you solved this ? > > > > I guess leaving 5-10 seconds between sending individual patches should > > overcome this? I wonder if git provides a built-in command for that? > > > > git send-email does provide the --batch-size --relogin-delay options, > as Ezequiel suggested me in #v4l. > > I tried re-sending with a 10 email batch and a 5 seconds delay but I > got the same failure. I was not able to find any description of the > email number limits for the SMTP server I'm using, so I could only go > and try. I think the extensive CC list of this series which I got from > Roman's series plays a role, so I can't try just by sending to > myself... I wonder if I should send the series in chunks, the first 10 > patches went out (2 times '-.- ) already... Any time you send a new batch, please call 'git send-email' with '--in-reply-to=<cover-letter-id>' to allow LKML front-ends identify the patches as belonging to one topic and make it less of a pain for people to go through these discussions later on.
Hi Eugeniu, On Tue, Jun 23, 2020 at 02:17:49PM +0200, Eugeniu Rosca wrote: > Hi Jacopo, > > On Tue, Jun 23, 2020 at 12:49:03PM +0200, Jacopo Mondi wrote: > > On Tue, Jun 23, 2020 at 12:30:02PM +0200, Eugeniu Rosca wrote: > > > On Mon, Jun 22, 2020 at 07:26:14PM +0200, Jacopo Mondi wrote: > > > > My ISP has rejected the rest of the series: too many emails :( > > > > Has it ever happened to anyone else ? How did you solved this ? > > > > > > I guess leaving 5-10 seconds between sending individual patches should > > > overcome this? I wonder if git provides a built-in command for that? > > > > > > > git send-email does provide the --batch-size --relogin-delay options, > > as Ezequiel suggested me in #v4l. > > > > I tried re-sending with a 10 email batch and a 5 seconds delay but I > > got the same failure. I was not able to find any description of the > > email number limits for the SMTP server I'm using, so I could only go > > and try. I think the extensive CC list of this series which I got from > > Roman's series plays a role, so I can't try just by sending to > > myself... I wonder if I should send the series in chunks, the first 10 > > patches went out (2 times '-.- ) already... > > Any time you send a new batch, please call 'git send-email' with > '--in-reply-to=<cover-letter-id>' to allow LKML front-ends identify > the patches as belonging to one topic and make it less of a pain > for people to go through these discussions later on. Thanks for the suggestion, I hope I got it right ;) The series has now been resent. Thanks j > > -- > Best regards, > Eugeniu Rosca
Hi Jacopo, On Wed, Jun 24, 2020 at 09:47:49AM +0200, Jacopo Mondi wrote: > On Tue, Jun 23, 2020 at 02:17:49PM +0200, Eugeniu Rosca wrote: > > Hi Jacopo, > > > > On Tue, Jun 23, 2020 at 12:49:03PM +0200, Jacopo Mondi wrote: > > > On Tue, Jun 23, 2020 at 12:30:02PM +0200, Eugeniu Rosca wrote: > > > > On Mon, Jun 22, 2020 at 07:26:14PM +0200, Jacopo Mondi wrote: > > > > > My ISP has rejected the rest of the series: too many emails :( > > > > > Has it ever happened to anyone else ? How did you solved this ? > > > > > > > > I guess leaving 5-10 seconds between sending individual patches should > > > > overcome this? I wonder if git provides a built-in command for that? > > > > > > > > > > git send-email does provide the --batch-size --relogin-delay options, > > > as Ezequiel suggested me in #v4l. > > > > > > I tried re-sending with a 10 email batch and a 5 seconds delay but I > > > got the same failure. I was not able to find any description of the > > > email number limits for the SMTP server I'm using, so I could only go > > > and try. I think the extensive CC list of this series which I got from > > > Roman's series plays a role, so I can't try just by sending to > > > myself... I wonder if I should send the series in chunks, the first 10 > > > patches went out (2 times '-.- ) already... > > > > Any time you send a new batch, please call 'git send-email' with > > '--in-reply-to=<cover-letter-id>' to allow LKML front-ends identify > > the patches as belonging to one topic and make it less of a pain > > for people to go through these discussions later on. > > Thanks for the suggestion, I hope I got it right ;) The series has now > been resent. That's right. I now see all 25 patches appearing under the same umbrella of https://patchwork.linuxtv.org/cover/64822/ (via "Related"), even if the last 15 have been sent out at a later point in time.