This message contains a digitally signed email which can be read by opening the attachment. Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--- Begin Message ---
- Subject: Re: [PATCH v2] drm/tilcdc: Precalculate total frametime in tilcdc_crtc_set_mode()
- From: Tomi Valkeinen <tomi.valkeinen@xxxxxx>
- Date: Fri, 13 Oct 2017 15:32:01 +0300
- Cc: <airlied@xxxxxxxx>, <laurent.pinchart@xxxxxxxxxxxxxxxx>, <kexin.hao@xxxxxxxxxxxxx>, <stable@xxxxxxxxxxxxxxx>
- In-reply-to: <be49d162-3db5-da09-f537-0947b0066695@ti.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
On 13/10/17 15:00, Jyri Sarha wrote: > On 10/13/17 14:04, Tomi Valkeinen wrote: >>> +uint tilcdc_mode_hvtotal(const struct drm_display_mode *mode) >>> +{ >>> + uint ret; >>> + >>> + ret = (uint) div_u64(1000llu * mode->htotal * mode->vtotal, >>> + mode->clock); >>> + >>> + return ret; >>> +} >> I don't think "uint" is recommended. Just use u32. And drop the ret >> variable, just one-line return statement should be enough. >> > > The ret variable can of course be dropped, but how u32 is better than > uint? If the driver would ever be used in 64bit architecture (highly > unlikely), then it would automatically use the higher precision, and on > 32-bit architecture there is no difference. I think int is normally 32 bit on 64 bit platforms too. But that depends on compiler flags. Where does "uint" come from anyway? I don't think it's part of a C standard. > Also the data member in the private struct is uint and so are the other > similar data members like lcd_fck_rate. Ok. Well, it's good to stick to one way of doing things, so maybe uint is fine. For any new code, I would not recommend using it. TomiAttachment: signature.asc
Description: OpenPGP digital signature
--- End Message ---