2017-03-06 14:37:26

by Javi Merino

[permalink] [raw]
Subject: [PATCH 0/2] Documentation/EDID fixes

Hi,

I found these two minor issues while building an EDID. I'm not sure
whether the second patch (Add O= to support) is upstream material, but
I'm sending it just in case.

Thanks,
Javi

Javi Merino (2):
drm: use .hword to represent 16-bit numbers
drm: Add O= support

Documentation/EDID/Makefile | 21 ++++++++++++---------
Documentation/EDID/edid.S | 6 +++---
2 files changed, 15 insertions(+), 12 deletions(-)

--
2.1.4


2017-03-06 14:38:10

by Javi Merino

[permalink] [raw]
Subject: [PATCH 1/2] drm: use .hword to represent 16-bit numbers

The size of .word is the size of a word in the given platform, which
for intel systems is 16-bits but other architectures use different
sizes. However, .hword emits 16-bit numbers regardless of the
platform (and despite the name). The quantities specified in EDID are
platform independent, so they should work in spite of the default
target of the cc you are using, so use .hword where EDID specifies
16-bit numbers.

Cc: Carsten Emde <[email protected]>
Cc: David Airlie <[email protected]>
Signed-off-by: Javi Merino <[email protected]>
---
Documentation/EDID/edid.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/EDID/edid.S b/Documentation/EDID/edid.S
index 7ac0327..ef082dc 100644
--- a/Documentation/EDID/edid.S
+++ b/Documentation/EDID/edid.S
@@ -59,9 +59,9 @@
/* Fixed header pattern */
header: .byte 0x00,0xff,0xff,0xff,0xff,0xff,0xff,0x00

-mfg_id: .word swap16(mfgname2id(MFG_LNX1, MFG_LNX2, MFG_LNX3))
+mfg_id: .hword swap16(mfgname2id(MFG_LNX1, MFG_LNX2, MFG_LNX3))

-prod_code: .word 0
+prod_code: .hword 0

/* Serial number. 32 bits, little endian. */
serial_number: .long SERIAL
@@ -177,7 +177,7 @@ std_vres: .byte (XY_RATIO<<6)+VFREQ-60

descriptor1:
/* Pixel clock in 10 kHz units. (0.-655.35 MHz, little-endian) */
-clock: .word CLOCK/10
+clock: .hword CLOCK/10

/* Horizontal active pixels 8 lsbits (0-4095) */
x_act_lsb: .byte XPIX&0xff
--
2.1.4

2017-03-06 14:41:32

by Javi Merino

[permalink] [raw]
Subject: [PATCH 2/2] drm: Add O= support

Add an option to put all output files in a given directory, similar to
what kbuild does.

Cc: Carsten Emde <[email protected]>
Cc: David Airlie <[email protected]>
Signed-off-by: Javi Merino <[email protected]>
---
Documentation/EDID/Makefile | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/Documentation/EDID/Makefile b/Documentation/EDID/Makefile
index 17763ca..76e8ef5 100644
--- a/Documentation/EDID/Makefile
+++ b/Documentation/EDID/Makefile
@@ -1,26 +1,29 @@

+# use "make O=dir" to locate all output files in "dir"
+O ?= .
+
SOURCES := $(wildcard [0-9]*x[0-9]*.S)

-BIN := $(patsubst %.S, %.bin, $(SOURCES))
+BIN := $(patsubst %.S, $(O)/%.bin, $(SOURCES))

-IHEX := $(patsubst %.S, %.bin.ihex, $(SOURCES))
+IHEX := $(patsubst %.S, $(O)/%.bin.ihex, $(SOURCES))

-CODE := $(patsubst %.S, %.c, $(SOURCES))
+CODE := $(patsubst %.S, $(O)/%.c, $(SOURCES))

all: $(BIN) $(IHEX) $(CODE)

clean:
- @rm -f *.o *.bin.ihex *.bin *.c
+ @rm -f $(O)/*.o $(O)/*.bin.ihex $(O)/*.bin $(O)/*.c

-%.o: %.S
- @cc -c $^
+$(O)/%.o: %.S
+ @cc -c $^ -o $@

-%.bin: %.o
+$(O)/%.bin: $(O)/%.o
@objcopy -Obinary $^ $@

-%.bin.ihex: %.o
+$(O)/%.bin.ihex: $(O)/%.o
@objcopy -Oihex $^ $@
@dos2unix $@ 2>/dev/null

-%.c: %.bin
+$(O)/%.c: $(O)/%.bin
@echo "{" >$@; hexdump -f hex $^ >>$@; echo "};" >>$@
--
2.1.4

2017-03-07 16:42:44

by Javi Merino

[permalink] [raw]
Subject: Re: [PATCH 0/2] Documentation/EDID fixes

On Tue, Mar 07, 2017 at 06:16:51PM +0200, Jani Nikula wrote:
> On Mon, 06 Mar 2017, Javi Merino <[email protected]> wrote:
> > I found these two minor issues while building an EDID. I'm not sure
> > whether the second patch (Add O= to support) is upstream material, but
> > I'm sending it just in case.
>
> I'm not opposed to fixing existing issues like this, but really I think
> there should be an userspace tool for this. Definitely outside of the
> Documentation directory, perhaps even outside the kernel tree
> altogether.

I am not sure whether this should be in the kernel or not, but I
agree that Documentation/ doesn't look like the right place to build
these files.

Cheers,
Javi

2017-03-07 20:00:25

by Jani Nikula

[permalink] [raw]
Subject: Re: [PATCH 0/2] Documentation/EDID fixes

On Mon, 06 Mar 2017, Javi Merino <[email protected]> wrote:
> I found these two minor issues while building an EDID. I'm not sure
> whether the second patch (Add O= to support) is upstream material, but
> I'm sending it just in case.

I'm not opposed to fixing existing issues like this, but really I think
there should be an userspace tool for this. Definitely outside of the
Documentation directory, perhaps even outside the kernel tree
altogether.

BR,
Jani.


--
Jani Nikula, Intel Open Source Technology Center

2017-03-08 08:12:25

by Jani Nikula

[permalink] [raw]
Subject: Re: [PATCH 0/2] Documentation/EDID fixes

On Tue, 07 Mar 2017, Javi Merino <[email protected]> wrote:
> On Tue, Mar 07, 2017 at 06:16:51PM +0200, Jani Nikula wrote:
>> On Mon, 06 Mar 2017, Javi Merino <[email protected]> wrote:
>> > I found these two minor issues while building an EDID. I'm not sure
>> > whether the second patch (Add O= to support) is upstream material, but
>> > I'm sending it just in case.
>>
>> I'm not opposed to fixing existing issues like this, but really I think
>> there should be an userspace tool for this. Definitely outside of the
>> Documentation directory, perhaps even outside the kernel tree
>> altogether.
>
> I am not sure whether this should be in the kernel or not, but I
> agree that Documentation/ doesn't look like the right place to build
> these files.

Just so there's no confusion: I'm just saying what I think should be
done in the long run. I'm not opposed to the fixes at hand, but someone
else needs to review them.

BR,
Jani.

--
Jani Nikula, Intel Open Source Technology Center